Arsitektur Data Salesforce

🌐 Juga tersedia dalam 28 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Panduan belajar untuk bab 3 kursus Data Architect. Baca dulu sepuluh modulnya; halaman ini membantu Anda memeriksa apa yang sudah melekat.

Tentang panduan belajar ini. Panduan ini disusun hanya dari konten kursus ini sendiri dan daftar tujuan yang tercantum dalam panduan ujian resmi Salesforce. Panduan ini tidak pernah didasarkan pada soal ujian yang sebenarnya, dan tidak mengklaim tahu apa yang keluar di ujian. Jika Anda sudah mengikuti ujiannya, mohon jangan kirimkan soal-soalnya kepada saya: perjanjian sertifikasi melarang membagikannya, dan menghafal jawaban memang cara yang salah untuk menjadi arsitek.

Inilah bab tempat model bertemu platform, dan bab ini memikul banyak bagian ujian. Bab ini mengisi kedua bagian terbesar, Data Modeling and Database Design serta Salesforce Data Management, masing-masing seperempat ujian. Angka-angka platform berubah: daftar periksa ini memberikan angka yang dikutip modul-modulnya, beserta tanggal pengecekannya. Pelajari untuk apa setiap batasan ada, dan periksa angka terkininya sebelum Anda mengandalkannya.

Untuk Ujian

Centang satu per satu sambil berjalan. Setiap poin bertaut ke tempat ia diajarkan.

DM-1: merancang model data di platform

• Saya tahu Salesforce adalah platform multitenant yang digerakkan metadata: sebuah objek adalah metadata, bukan tabel baru, dan setiap objek mendapat API-nya begitu ia ada. (Metadata Adalah Cetak Birunya, API Anda Datang Bersama Objeknya)
• Saya tahu governor limit ada agar satu penyewa tidak bisa menguasai sumber daya bersama. (Anda Tidak Boleh Menguasai Lift)
• Saya bisa membaca model data standar: konversi Prospek menjadi Akun, Kontak, dan Peluang; Produk Peluang (Opportunity Product) menunjuk ke Entri Buku Harga (Price Book Entry), yang menunjuk ke Product2; serta Kasus, Aset, dan Hak Layanan (Entitlement) di sisi layanan. (Model Penjualan, Model Layanan)
• Saya tahu apa yang diputuskan layar New Custom Object (Objek Kustom Baru): nama rekaman berupa Text atau Auto Number; Object Classification (dengan berbagi, Bulk API, dan Streaming API aktif ia adalah objek Enterprise Application, dengan semuanya nonaktif ia adalah objek Light Application); dan Allow Search (Izinkan Pencarian), nonaktif secara bawaan. (Layar New Custom Object)
• Saya bisa membaca nama API: objek dan bidang standar tidak punya prefiks atau sufiks; objek dan bidang kustom berakhiran __c; paket terkelola menambahkan prefiks namespace-nya (abc__); dan bidang yang Anda tambahkan ke objek milik paket mendapat __c tetapi tidak pernah prefiks vendornya. (Prefiks dan Sufiks)
• Saya bisa menerapkan uji kecocokan yang rapi untuk objek standar, dan saya tahu kapan makna atau beban mengarah ke objek kustom. (Uji Kecocokan yang Rapi)
• Saya tahu untuk apa Aset dan akun pribadi, bahwa akun pribadi memakan sekitar dua kali penyimpanan akun bisnis, dan bahwa begitu akun pribadi diaktifkan, ia tidak bisa dinonaktifkan. (Aset Adalah Contoh yang Baik, Akun Pribadi, Kapan Orangnya Menjadi Akun?)
• Saya memilih tipe bidang untuk perilaku yang saya butuhkan (nomor armada bukanlah Number), dan saya tahu date/time disimpan dalam GMT dan ditampilkan dalam zona waktu setiap pembaca, sehingga dibandingkan dengan rentang, bukan dengan kesamaan. (Angka Tidak Selalu Angka, Date, Date/Time, dan Time)
• Saya tahu teks ada dua jenis: hingga 255 karakter di rekaman (bisa diindeks, bisa dipakai sebagai unik atau External ID), dan teks Long atau Rich di atas itu, tanpa indeks, tanpa pemfilteran WHERE, dan tanpa formula. (Keluarga Teks)
• Saya tahu kapan memakai Name dengan penomoran otomatis, dan bahwa itu bukan ID rekaman. (Apakah Manusia Perlu Mengidentifikasinya?)
• Saya tahu bagaimana External ID memungkinkan integrasi melakukan upsert, dan memuat anak berdasarkan External ID induknya. (External ID)
• Saya tahu kapan sebuah nilai sebaiknya diturunkan oleh formula, dan kapan ia fakta historis yang harus disimpan. (Disimpan atau Diturunkan?)
• Saya tahu perbedaan antara objek penghubung logis (ide pemodelan: objek yang menggabungkan dua objek lain dalam hubungan banyak-ke-banyak, dengan atributnya sendiri) dan Junction Object Salesforce (objek penghubung Salesforce: objek kustom dengan dua hubungan master-detail), dan bahwa yang dimaksud Salesforce adalah yang kedua. (Dua Induk ke Samping)
• Saya tahu hubungan hierarkis: lookup khusus yang hanya ada di objek User, seperti bidang Manager standar, yang tidak bisa berputar kembali ke pengguna yang sama secara langsung maupun tidak langsung, dan bukan hierarki peran. (Hierarkis)
• Saya tahu perbedaan antara lookup dan master-detail: kepemilikan, berbagi, induk wajib, penghapusan berantai, ringkasan roll-up. (Lookup, Master-Detail)
• Saya tahu master-detail tidak bisa dibuat pada objek yang sudah berisi data (buat lookup, isi, lalu ubah), hanya bisa dikembalikan menjadi lookup jika tidak ada roll-up di master, dan butuh Allow reparenting untuk memindahkan anak. (Bisakah Anak Berganti Induk?)
• Saya tahu bentuk platform untuk master-detail: hingga tiga tingkat detail kustom ke dalam (sebuah lookup bisa memutus rantainya di mana saja), dan dua induk master-detail ke samping. Pada Junction Object Salesforce, master-detail yang dibuat pertama adalah yang utama (pemilik, tampilan, divisi), yang kedua adalah sekunder, dan akses membutuhkan kedua induk: yang paling ketat yang menang. (Tiga Tingkat ke Dalam, Dua Induk ke Samping)
• Saya tahu tiga pilihan lookup ketika induknya dihapus: kosongkan bidangnya (bawaan), blokir penghapusannya, atau hapus berantai, yang nonaktif sampai Salesforce mengaktifkannya dan melewati pengaturan berbagi. (Lookup)
• Saya tahu hubungan dengan diri sendiri harus berupa lookup, dan dua yang sudah tersedia bawaan: Akun Induk (Parent Account) pada Akun dan Kasus Induk (Parent Case) pada Kasus. (Hubungan dengan Diri Sendiri)
• Saya tahu perhitungan ulang roll-up bisa butuh waktu, bahwa roll-up tidak bisa memakai formula dengan NOW(), TODAY(), atau referensi lintas objek, dan tidak memilih master-detail hanya demi mendapat roll-up: bidang tersimpan yang dijaga tetap terkini oleh flow atau trigger adalah alternatifnya. (Roll-Up Itu Berguna, tetapi Tidak Gratis)
• Saya tahu batasan hubungan yang dikutip modulnya: dua master-detail per objek; 40 bidang hubungan secara bawaan (paling banyak 50); 25 roll-up secara bawaan (paling banyak 40). (Hubungan Juga Punya Batasan)

DM-2: model yang menghormati berbagi dan bisa diskalakan

• Saya tahu anak master-detail tidak punya pemilik dan tabel berbagi sendiri: aksesnya mengikuti master. (Kepemilikan Ikut Terbawa)
• Saya tahu parent-child skew: panduan Salesforce adalah tidak lebih dari sekitar 10.000 anak pada satu induk. (Pertanyaan 10.000 Anak)
• Saya tahu ownership skew (satu pengguna memiliki lebih dari 10.000 rekaman sebuah objek) dan panduannya: sebarkan kepemilikan, atau jauhkan pengguna itu dari hierarki peran atau tempatkan sendirian di puncak, dan jauhkan dari grup publik yang dipakai aturan berbagi. (Kepemilikan Bisa Menjadi Masalah Skala)
• Saya tahu tabel berbagi (share table): objek berbagi milik objek kustom adalah Object__Share; objek detail tidak punya, aksesnya datang dari master; dan pergantian pemilik menghapus berbagi manual tetapi mempertahankan berbagi Apex yang punya alasannya sendiri. (Tabel Berbagi)
• Saya bisa memutuskan siapa pemilik rekaman yang dibuat integrasi dan agen, berdasarkan apakah kepemilikan menentukan berbagi. (Siapa Pemilik Rekaman yang Dibuat Sistem?)

DM-4: big object dibandingkan objek standar dan kustom

• Saya tahu tiga rumah untuk data: di core (sObject, dipakai setiap hari), dirujuk (sistem lain adalah sumber kebenaran: objek eksternal Salesforce Connect, __x, atau panggilan kustom), dan diarsipkan (di core dalam big object, __b, atau di luar core (off-core) dalam data warehouse). (Di Core dan di Luar Core)
• Saya tahu objek eksternal melakukan callout setiap kali disentuh, jadi latensi dan ketersediaan sistem sumber itu penting. (Dirujuk)
• Saya tahu big object: volume sangat besar, dikueri melalui indeksnya dengan pencocokan persis atau rentang, tanpa UI atau pelaporan standar, hanya izin objek dan bidang, tanpa otomatisasi. (Diarsipkan)
• Saya tahu sebagian besar rekaman dihitung sekitar 2 KB penyimpanan data berapa pun jumlah bidangnya, dan bahwa file diukur terpisah di penyimpanan file. (Dua Kolom atau Dua Ratus, File dan Lampiran)

SDM-1: lisensi dan objek yang bisa dipakai orang

• Saya tahu tiga lisensi internal, Sales Cloud, Service Cloud, dan Platform, dan apa yang bisa dipakai masing-masing. (Tiga Lisensi Internal)
• Saya tahu lisensi adalah bagian dari model data: pengguna Salesforce Platform tidak mendapat Prospek, Kampanye, Peluang, atau Prakiraan, dan pengguna Customer Community tidak bisa memakai Peluang. (Sekarang Saya Akan Memperumit Semuanya: Lisensi)
• Saya tahu tingkatan lisensi eksternal: Customer Community, Customer Community Plus (laporan, dasbor, berbagi standar), Partner Community (objek penjualan); dan bahwa Partner Community tidak bisa dipakai dengan akun pribadi. (Stadion)
• Saya tahu lisensi berbasis anggota dibandingkan berbasis login, dan populasi mana yang cocok untuk masing-masing. (Cara Mereka Membayar Mengubah Desainnya)
• Saya tahu sebagian lisensi platform membatasi pengguna pada satu aplikasi dengan paling banyak sepuluh objek kustom, dan pola tipe rekaman untuk bekerja di dalam batasan itu. (Ketika Lisensi Membentuk Model)
• Saya tahu lisensi Salesforce Integration ditujukan untuk pengguna antarsistem yang hanya memakai API. (Manusia Bukan Lagi Satu-satunya Pengguna)
• Saya tahu pelaporan SLA butuh entitlement dan milestone, yang butuh lisensi Service. (Sekarang Saya Akan Memperumit Semuanya: Lisensi)

SDM-2: menjaga data tetap konsisten

• Saya bisa menempatkan sebuah aturan di anak tangga yang tepat pada tangga konsistensi: tipe bidang dan kosakata, wajib dan unik, aturan validasi, aturan duplikat, otomatisasi. (Menjaga Data Tetap Konsisten)
• Saya tahu daftar pilihan terbatas menolak nilai yang tidak ada di daftar, bahkan melalui API, dan set nilai global berbagi satu daftar lintas bidang (hingga 1.000 nilai). (Anak Tangga Pertama)
• Saya tahu persyaratan di tata letak halaman hanya melindungi layar itu, bukan datanya, dan bahwa aturan validasi berjalan di setiap penyimpanan. (Validasi UI Bukanlah Validasi Data, Anak Tangga Ketiga)
• Saya bisa membatasi cakupan aturan validasi dengan ISNEW() dan ISCHANGED(), izin kustom, atau tanggal mulai berlaku, sambil mengetahui penyimpanan mana (termasuk yang tidak saya kendalikan, seperti perubahan pemilik secara batch atau roll-up) yang masih diperiksa oleh setiap pilihan. (Masalah Rekaman Lama)
• Saya tahu aturan pencocokan dan aturan duplikat, batasan yang dikutip modulnya (lima aturan duplikat aktif per objek, masing-masing tiga aturan pencocokan), dan bahwa semuanya tidak menyelesaikan identitas lintas sistem. (Anak Tangga Keempat: Aturan Duplikat)
• Saya tahu aturan duplikat tidak membandingkan rekaman yang disimpan pada saat yang sama, bahwa penyimpanan melalui API dan impor diblokir tanpa peringatan, dan bahwa sebuah penyimpanan beserta semua yang dipicunya dibatalkan sebagai satu transaksi. (Anak Tangga Keempat, Semua atau Tidak Sama Sekali)
• Saya tahu Workflow Rules dan Process Builder sudah tidak didukung; otomatisasi berarti Flow atau Apex. (Anak Tangga Kelima: Otomatisasi)

Di Luar Ujian

Ujian adalah batas bawah, bukan batas atas. Inilah kebiasaan dari bab ini yang dibutuhkan seorang arsitek, entah ada pertanyaan ujian tentangnya atau tidak.

• Platform punya bentuk. Rancanglah untuk platform yang Anda pakai, bukan untuk database generik.
• Lihat ke kapal induk. Lihat bagaimana Salesforce memodelkan sebuah konsep sebelum Anda menciptakannya sendiri.
• Setiap objek adalah komitmen: penyimpanan, batasan, model berbagi, lisensi, dan ketergantungan.
• Tanyakan di mana data tinggal sebelum Anda memilih objek: di core, dirujuk, atau diarsipkan.
• Baca nama API apa pun dan Anda tahu siapa pembuatnya, dan apa yang bisa Anda ubah.
• Jika Anda tidak mengarsipkan hari ini, apakah Anda akan pernah mengarsipkan?
• Buat prototipe big object sebelum Anda menyarankannya.
• Nama bisnis yang berbeda tidak otomatis berarti objek yang berbeda.
• Tanyakan identitas mana yang butuh datanya: orang, pelanggan, mitra, integrasi, dan agen.
• Setiap bidang mendapat deskripsi, dan klasifikasi di tempat yang penting.
• Gambarkan perilaku hubungannya lebih dulu; konfigurasilah yang mengimplementasikannya. Jangan memelintir model demi mendapat sebuah fitur.
• Pertanyaan penghapusan: apa yang seharusnya terjadi pada anak-anaknya jika seseorang menghapus induknya?
• Pilih tautan mana yang memutus rantainya: jadikan lookup di tempat anak benar-benar punya hidupnya sendiri.
• Kepemilikan dari yang utama, akses dari keduanya: yang paling ketat yang menang.
• Pisahkan tidak aktif dari hilang, dan jadikan retensi sebagai aturan bisnis.
• Dorong aturan serendah tempat yang benar baginya, dan beri riwayat yang sah jalan pintas alih-alih menulisnya ulang.
• Diagram bukanlah arsitekturnya. Mampulah menelusuri setiap struktur kembali ke alasan bisnisnya.

Istilah Penting

Istilah	Dalam satu baris
Digerakkan metadata	Objek dan bidang adalah definisi yang dibaca platform saat runtime, bukan tabel fisik baru
Multitenancy	Banyak org berbagi infrastruktur, masing-masing terisolasi, seperti unit apartemen di satu gedung
Governor limit	Batasan yang mencegah satu penyewa memonopoli sumber daya bersama
Objek eksternal	Data yang ditampilkan di Salesforce melalui Salesforce Connect, diambil dari sumbernya setiap kali disentuh
Big object	Penyimpanan untuk data yang sangat besar dan jarang dipakai, dikueri melalui indeksnya
Akun pribadi	Seorang individu yang direpresentasikan sebagai akun, untuk model bisnis ke konsumen
Kecocokan yang rapi	Konsep bisnis yang sesuai dengan tujuan yang dimaksud dari sebuah objek standar
External ID	Bidang yang menyimpan pengenal sistem lain, dipakai untuk upsert dan pencocokan
Upsert	Perbarui rekaman jika sudah ada, buat jika belum
Lookup	Hubungan di mana anak tetap punya pemilik dan hidupnya sendiri
Master-detail	Hubungan di mana anak menjadi milik induk: pemilik dan berbagi diwarisi, penghapusan berantai, roll-up
Objek penghubung logis	Ide pemodelan: objek yang menggabungkan dua objek lain dalam hubungan banyak-ke-banyak dan membawa atributnya sendiri, bagaimanapun ia dibangun
Junction Object Salesforce	Yang dimaksud Salesforce dengan “junction object”: objek kustom dengan dua hubungan master-detail
Master utama dan sekunder	Master-detail yang dibuat pertama pada Junction Object Salesforce (pemilik, tampilan, divisi) dan yang kedua (cakupan laporan; menjadi utama jika yang pertama dihapus)
Hubungan hierarkis	Lookup khusus yang hanya ada di objek User, seperti Manager, yang tidak bisa berputar kembali ke pengguna yang sama
Prefiks namespace	Prefiks vendor pada objek dan bidang paket terkelola, seperti abc__Inspection__c
Tabel berbagi	Objek berbagi (AccountShare, Truck__Share) yang menyimpan sebagian besar pengaturan berbagi sebuah rekaman, satu baris per pengguna atau grup, beserta alasannya
Ringkasan roll-up	Bidang di master yang menghitung, menjumlahkan, atau mencari nilai minimum atau maksimum dari detail-detailnya
Data skew	Terlalu banyak rekaman di bawah satu induk atau satu pemilik, yang menyebabkan penguncian dan perhitungan ulang berbagi yang lama
Berbasis anggota / berbasis login	Membayar per pengguna eksternal, atau per login setiap bulan
Tangga konsistensi	Lapisan-lapisan yang menegakkan aturan data, dari tipe bidang hingga otomatisasi
Daftar pilihan terbatas	Daftar pilihan yang menolak nilai apa pun yang tidak ada di daftarnya, dari sumber mana pun
Klasifikasi data	Metadata bidang untuk pemilik, pemakaian, sensitivitas, dan kategori kepatuhan

Uji Diri

Skenario singkat dengan gaya kursus ini. Tentukan jawaban Anda sebelum membukanya.

1. Pengguna perlu melihat detail pesanan yang dimiliki dan diperbarui ERP sepanjang hari. Mereka tidak mengeditnya di Salesforce. Salin masuk, atau tidak?

Rujuk saja: objek eksternal melalui Salesforce Connect menjaga ERP tetap sebagai sumber kebenaran tanpa salinan yang perlu disinkronkan. Terima bahwa setiap tampilan melakukan callout, jadi latensi dan ketersediaan ERP itu penting, dan bahwa cara ini lebih cocok untuk akses baca daripada pengeditan atau pelaporan yang intensif. Baca lagi Dirujuk.

2. Bisnis ingin melacak distributor, pemasok, dan mitra ritel. Tiga objek kustom?

Tidak. Semuanya perusahaan, jadi Akun cocok dengan rapi; nama-nama yang berbeda itu adalah peran, yang dibawa oleh tipe, tipe rekaman, atau hubungan. Baca lagi Uji Kecocokan yang Rapi.

3. Sebuah desain memakai Peluang, tetapi sebagian besar orang yang butuh datanya punya lisensi Salesforce Platform atau Customer Community. Lalu bagaimana?

Lisensi-lisensi itu tidak bisa memakai Peluang, jadi lisensinya adalah batasan arsitektur: beli lisensi yang berbeda, pindahkan pengalamannya, atau rancang ulang, biasanya ke arah objek kustom. Baca lagi Sekarang Saya Akan Memperumit Semuanya: Lisensi.

4. ERP mengirim pembaruan akun setiap malam. Bagaimana integrasi seharusnya menemukan rekaman yang tepat tanpa mengkueri ID Salesforce?

Simpan nomor pelanggan ERP di bidang External ID dan lakukan upsert berdasarkan bidang itu: perbarui jika ditemukan, buat jika tidak. Rekaman anak juga bisa menunjuk induknya melalui External ID-nya. Baca lagi External ID.

5. Sebuah Item Pengiriman tidak bisa ada tanpa pengirimannya, tidak pernah berpindah, dan tidak butuh pemilik sendiri. Sebuah Pengiriman ada sebelum dirutekan dan bisa pindah ke rute lain. Hubungan apa untuk masing-masing?

Item Pengiriman ke Pengiriman: master-detail (milik induknya seumur hidup, mewarisi akses, ikut terhapus). Pengiriman ke Rute: lookup (punya hidupnya sendiri, opsional di awal, bisa dipindahkan, dan menghapus rute tidak boleh pernah menghapus pengiriman). Baca lagi Mulailah dari Hubungan Bisnisnya.

6. Sebuah integrasi membuat 3.300 pengiriman per hari, semuanya dimiliki pengguna integrasi, yang punya peran di tengah hierarki. Apa risikonya, dan perbaikannya?

Ownership skew: melewati 10.000 rekaman, memindahkan pengguna itu atau mengubah grupnya memicu perhitungan ulang berbagi yang lama. Sebarkan kepemilikan jika kepemilikan penting untuk akses; jika tidak, jauhkan pengguna integrasi dari hierarki peran, atau tempatkan sendirian di peran di puncak, dan jauhkan dari grup yang dipakai aturan berbagi. Baca lagi Kepemilikan Bisa Menjadi Masalah Skala.

7. Anda menambahkan aturan validasi, dan 20.000 rekaman lama melanggarnya. Seorang pengguna mengedit nomor telepon di salah satunya dan penyimpanannya gagal. Apa yang seharusnya dilakukan aturan itu?

Menyatakan kapan ditegakkan, bukan hanya apa yang harus benar: batasi cakupannya dengan ISNEW() atau ISCHANGED() pada bidang yang relevan, dan beri rekaman yang lebih tua dari aturan itu jalan pintas yang disengaja alih-alih menulis ulang riwayatnya. Baca lagi Masalah Rekaman Lama.

8. Bisnis ingin setiap foto pengiriman ada "di Salesforce": empat sampai lima juta per tahun, bertumbuh 30 persen. Apa usulan Anda?

Pisahkan akses dari penyimpanan. Simpan file-filenya di penyimpanan yang dibangun untuk volume itu, di luar org core, dan simpan rujukan, jumlah, atau rekaman indeks di Salesforce agar pengguna bisa menemukan dan melihatnya. Baca lagi Foto.

9. Sebuah Penugasan Kru (Crew Assignment) punya hubungan master-detail ke Kru (dibuat pertama) dan Truk. Seorang dispatcher bisa melihat kru tetapi tidak bisa melihat truk. Bisakah ia melihat Penugasan Kru itu?

Tidak. Kru adalah yang utama, jadi ia memberi penugasan itu pemilik dan tampilannya, tetapi akses membutuhkan kedua induk: dispatcher butuh akses ke kru dan truk, pada tingkat yang diminta oleh Sharing Setting di setiap bidang master-detail. Yang paling ketat yang menang. Baca lagi Dua Induk ke Samping.

10. Seorang mitra mengirim ulang file manifes, dan pelanggan yang sama muncul dua kali di dalamnya. Anda punya aturan duplikat di Akun yang diatur untuk memblokir. Apakah Anda aman?

Tidak hanya dengan aturan duplikat. Rekaman yang disimpan pada saat yang sama tidak dibandingkan satu sama lain, hanya dengan rekaman yang sudah ada di Salesforce, jadi kedua baris bisa lolos. Dorong keunikan ke tingkat bidang: External ID yang unik, yang diperiksa platform di setiap penyimpanan, sehingga hanya satu yang menang. Baca lagi Anak Tangga Keempat: Aturan Duplikat dan Semua atau Tidak Sama Sekali.

Jelajahi

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Bantuan Salesforce (dicek 2026-09-25, bahasa Inggris): daftar resmi tujuan ujian dan bobotnya. Selalu periksa versi terkininya sebelum Anda mendaftar ujian.
• Bagian Jelajahi di setiap modul mencantumkan dokumentasi Salesforce di balik fakta-fakta platformnya, beserta tanggal pengecekannya.