Hubungan Punya Konsekuensi

🌐 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

Modul 7 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Bidang Juga Bagian dari Arsitektur · Berikutnya: Kepemilikan dan Siklus Hidup

Pertanyaan yang dijawab modul ini: Apa sebenarnya yang saya pilih ketika menghubungkan dua objek Salesforce?

Menggambar sebuah hubungan itu mudah. Di bab 2 kita menggambar garis dan memberinya nama: sebuah Mitra Ritel mengirim banyak manifes, sebuah pengiriman membawa banyak item, kru dan truk bertemu dalam Penugasan Kru. Kita membahas kardinalitas, opsionalitas, dan riwayat. Sekarang kita mengimplementasikan garis-garis itu di Salesforce, dan sebuah garis di diagram mulai memikul beban yang jauh lebih berat.

Ketika memilih tipe hubungan di Salesforce, saya tidak hanya mengatakan kedua rekaman ini terhubung. Saya mungkin juga memutuskan siapa pemilik anaknya, apakah ia bisa ada tanpa induknya, siapa yang bisa melihatnya, apa yang terjadi ketika induknya dihapus, apakah ia bisa pindah ke induk lain, apakah saya bisa meringkasnya ke induk, dan apa yang terjadi ketika ada ratusan ribu anak. Hubungan bukan sekadar garis. Hubungan membawa perilaku.

Mulailah dari Hubungan Bisnisnya

Sebelum lookup atau master-detail, kembali ke bisnisnya. Ambil sebuah Pengiriman dan Item Pengirimannya, kulkasnya, pemasangannya, pengangkutan barang lamanya. Bisakah sebuah item ada tanpa pengirimannya? Tidak. Jika pengirimannya dihapus, haruskah item-itemnya ikut terhapus? Ya. Apakah item-item itu butuh pemilik atau keamanannya sendiri? Tidak juga. Haruskah seseorang memindahkan item dari satu pengiriman ke pengiriman lain? Semoga tidak secara tidak sengaja.

Sekarang ambil sebuah Pengiriman dan Rute tempat ia berada. Pengiriman ada sebelum dimasukkan ke rute, ia bisa dipindahkan ke rute lain ketika rencananya berubah, dan menghapus sebuah rute tidak boleh menghapus pengiriman-pengiriman di dalamnya. Dua garis satu-ke-banyak yang terlihat sama di diagram, dengan perilaku yang sama sekali berbeda. Perhatikan bahwa kita masih belum menyebut “lookup” atau “master-detail.” Gambarkan perilakunya lebih dulu. Konfigurasilah yang mengimplementasikannya.

Tipe-Tipe Hubungan

Buka layar New Field (Bidang Baru), dan Salesforce menawarkan beberapa tipe hubungan (Object Relationships Overview (opens in a new tab)):

• Lookup: menghubungkan dua objek. Menu utama hubungan di Salesforce, yang Anda pakai sehari-hari.
• Master-detail: ikatan induk-anak di mana induk mengendalikan anaknya.
• Banyak-ke-banyak: bukan tipe bidang tersendiri, melainkan sebuah pola: sebuah Junction Object Salesforce (objek penghubung Salesforce), yaitu objek kustom dengan dua master-detail.
• Hubungan dengan diri sendiri: lookup dari sebuah objek ke dirinya sendiri.
• Hierarkis: lookup khusus yang hanya ada di objek User (Pengguna), misalnya manajer seorang pengguna.
• External lookup dan indirect lookup: hubungan ke dan dari objek eksternal, yaitu objek __x dari modul 4. External lookup menunjuk ke objek eksternal induk; indirect lookup menunjuk dari objek eksternal ke objek standar atau kustom, dicocokkan berdasarkan ID Eksternal yang unik.

Sebagian besar waktu desain Anda tercurah untuk tiga yang pertama. Mari kita bahas satu per satu.

Lookup: Rekaman-Rekaman Ini Terhubung

Lookup mengatakan: rekaman ini terkait dengan rekaman itu. Anak tetap punya identitasnya sendiri, pemiliknya sendiri, dan hidupnya sendiri. Sebuah Pengiriman menunjuk ke Rute-nya. Jika rutenya dibatalkan, pengiriman-pengirimannya tidak lenyap; semuanya kembali untuk dirutekan ulang.

Lucunya begini: bidang lookup ditaruh di anak, tetapi induknya juga mendapat sesuatu, yaitu related list (daftar terkait) berisi anak-anaknya. Jadi saat membuatnya, beri nama kedua ujungnya. Related List Label adalah yang dilihat orang di induk, dan Child Relationship Name adalah yang dipakai developer dan integrasi untuk berjalan dari induk ke anak-anaknya. Jangan terima nilai bawaannya begitu saja.

Lookup bisa wajib atau opsional. Jika opsional, Anda memutuskan apa yang terjadi jika rekaman yang ditunjuknya dihapus, dan ada tiga pilihan (Considerations for Object Relationships (opens in a new tab)):

• Clear the value of this field (kosongkan nilai bidang ini), pilihan bawaan. Anak tetap ada, dengan lookup yang kosong.
• Don’t allow deletion (jangan izinkan penghapusan) rekaman lookup. Coba hapus rutenya, dan Salesforce menolak: rute itu bagian dari sebuah hubungan.
• Delete this record also (hapus juga rekaman ini), penghapusan berantai, seperti master-detail. Pilihan ini hanya tersedia untuk lookup kustom di objek kustom, dinonaktifkan secara bawaan, dan Salesforce harus mengaktifkannya untuk org Anda, karena penghapusan berantai melewati keamanan dan berbagi: pengguna bisa menghapus rekaman yang bahkan tidak bisa mereka lihat.

Itu keputusan siklus hidup yang bersembunyi di layar setup.

Lookup filter (filter lookup) mempersempit apa yang bisa dipilih pengguna. Misalkan Pengiriman punya lookup Installer (Pemasang) ke Kontak, dan pemasang hanyalah satu tipe rekaman kontak di antara banyak tipe lain. Filter lookup hanya menampilkan pemasang, dan filter itu bisa menyaring berdasarkan rekaman saat ini, rekaman yang sedang dicari, dan penggunanya: profil, peran, atau izinnya (Lookup Filters (opens in a new tab)). Ini cara murah untuk menjaga lookup tetap jujur.

Master-Detail: Anak Ini Milik Induk Itu

Master-detail membuat pernyataan yang jauh lebih kuat. Di kelas saya menyebutnya ikatan yang sangat erat. Anda tidak bisa punya detail tanpa master-nya; bidang master-nya wajib. Detail kehilangan bidang Owner-nya sendiri dan mewarisi pemilik induknya. Tidak ada tabel berbagi (share table) terpisah untuk detail, jadi Anda tidak bisa membagikan seorang anak secara tersendiri; ia mewarisi pengaturan berbagi induknya. Itulah sebabnya objek detail tidak bisa punya aturan berbagi, berbagi manual, atau antrean: semuanya butuh bidang Owner (Object Relationships Overview (opens in a new tab)). Di Setup, pengaturan berbaginya tertulis Controlled by Parent (dikendalikan oleh induk). Dan di bidang master-detail itu sendiri Anda memilih Sharing Setting (pengaturan berbagi): apakah pengguna butuh akses Read Only atau Read/Write ke master untuk membuat, mengedit, atau menghapus detailnya. Menghapus master menghapus detail-detailnya. Dan master mendapat bidang ringkasan roll-up.

Jadi jika Item Pengiriman adalah detail dari Pengiriman, saya sedang mengatakan: item ini milik pengiriman ini sepanjang hidupnya. Itulah pertanyaan yang ingin saya jawab sebelum siapa pun memilih Master-Detail Relationship di Setup.

Pertanyaan Penghapusan

Inilah cara favorit saya untuk mengetahui apakah kita sudah memikirkannya dengan matang: apa yang seharusnya terjadi pada anak-anaknya jika seseorang menghapus induknya? Semua orang menjadi tidak nyaman. Bagus. Sekarang kita sedang melakukan arsitektur.

Sebuah Mitra Ritel punya ratusan ribu pengiriman historis. Seseorang menghapus mitra itu. Haruskah pengiriman-pengirimannya hilang? Hampir pasti tidak: klaim, penagihan, dan riwayat semuanya bergantung padanya. Mungkin menghapus mitra sama sekali tidak boleh dilakukan, dan mitranya seharusnya dinonaktifkan saja. Dengan master-detail, menghapus master akan berantai ke detail dan detail-detailnya; memulihkan master akan mengembalikan semuanya (Considerations for Object Relationships (opens in a new tab)). Jadi ketika seseorang berkata “master-detail memberi kita roll-up,” jawaban saya: bagus. Apa lagi yang baru saja Anda setujui?

Kepemilikan Ikut Terbawa

Dengan lookup, anak bisa punya pemiliknya sendiri. Dengan master-detail, tidak bisa; aksesnya mengikuti master. Itu persis tepat jika detail memang bagian dari induknya. Tetapi jika anak butuh pemiliknya sendiri, pengaturan berbaginya sendiri, atau siklus hidupnya sendiri, model sedang memberi tahu Anda bahwa master-detail adalah pilihan yang salah. Modul berikutnya membahas kepemilikan lebih dalam, dan kursus Sharing and Visibility membahasnya lebih jauh lagi. Untuk sekarang: desain hubungan dan desain keamanan bukanlah percakapan yang terpisah. Model data membentuk model keamanan sebelum ada yang menulis aturan berbagi.

Induk Wajib, atau Opsional?

Bisakah anak ada sebelum kita tahu induknya? Ini lebih penting daripada kedengarannya. Jika pengiriman tiba di manifes malam sebelumnya dan rute dibangun sesudahnya, Rute yang wajib di Pengiriman berarti perutean harus terjadi sebelum rekaman bahkan bisa dibuat. Hubungan fisik harus mendukung siklus hidup yang nyata. Jadi saya tidak merancang hubungan hanya dari diagram yang statis. Saya ingin tahu: bagaimana mereka lahir, bisakah mereka berdiri sendiri, bisakah mereka pindah, dan bagaimana mereka mati?

Bisakah Anak Berganti Induk?

Secara bawaan, anak master-detail tidak bisa dipindahkan ke induk lain. Anda bisa mengizinkannya, dengan memilih Allow reparenting (Izinkan penggantian induk) pada hubungan itu (Considerations for Object Relationships (opens in a new tab)). Naluri saya konservatif: jika bisnis bilang anak itu milik satu induk seumur hidupnya, saya tidak membuat pemindahannya mudah. Item yang berpindah dari satu pengiriman ke pengiriman lain seharusnya merupakan peristiwa bisnis yang disengaja, bukan suntingan bidang. Sekali lagi, pengaturannya bukanlah arsitekturnya. Aturan siklus hiduplah arsitekturnya, dan pengaturan itu mengimplementasikannya.

Dua hal lagi yang belakangan sering membuat tim kerepotan. Anda tidak bisa membuat hubungan master-detail pada objek yang sudah berisi data; Anda membuat lookup, mengisinya di setiap rekaman, lalu mengubahnya. Dan Anda hanya bisa mengubahnya kembali menjadi lookup jika tidak ada bidang ringkasan roll-up di master. Perhatikan juga apa yang dilakukan konversi itu terhadap keamanan: mengubah lookup menjadi master-detail mengatur pengaturan berbagi anak menjadi Controlled by Parent, dan mengubah master-detail kembali menjadi lookup mengatur organization-wide default anak menjadi Public Read/Write (Considerations for Object Relationships (opens in a new tab)). Rekaman yang kemarin privat hari ini terbuka, sampai seseorang menyadarinya. Pilihlah sejak awal.

Roll-Up Itu Berguna, tetapi Tidak Gratis

Saya suka roll-up. Hitung item di sebuah pengiriman, jumlahkan nilai baris di sebuah faktur, temukan tanggal terbaru: bawaan, tanpa kode. Bidang master-detail ditaruh di anak, tetapi roll-up ditaruh di induk. Namun ada syarat dan ketentuannya (Roll-Up Summary Field (opens in a new tab)):

• Menghitung nilai roll-up setelah perubahan tertentu (bidang roll-up baru, formula yang menjadi tumpuannya berubah, perhitungan ulang yang dipaksakan) bisa memakan waktu hingga 30 menit, tergantung berapa banyak rekaman yang terpengaruh. Saya pernah melihat orang bingung mengapa angka di induk belum berubah juga.
• Roll-up tidak bisa meringkas segalanya. Penomoran otomatis tidak bisa menjadi bidang yang diagregasi. Dan roll-up hanya bisa meringkas bidang formula jika formula itu tidak menjangkau objek lain dan tidak memakai fungsi yang berubah dengan sendirinya, seperti NOW() atau TODAY(). Formula “hari keterlambatan” yang dibangun di atas TODAY() berubah setiap malam tanpa ada yang menyimpan rekaman, sehingga tidak ada pemicu bagi roll-up untuk menghitung ulang. Angka semacam itu butuh flow terjadwal, atau laporan.
• Filternya juga punya batasan: tidak bisa memakai area teks panjang, daftar pilihan multi-pilih, Description, bidang sistem seperti Last Activity, formula lintas objek, atau bidang lookup.
• Roll-up tidak ada di halaman edit, jadi aturan validasi bisa memakainya tetapi tidak bisa menampilkan pesan galatnya di sana.

Dan jangan membalik keputusannya. Jangan berkata, “Kita butuh roll-up, jadi ini harus master-detail.” Katakan, “Anak ini benar-benar milik induk ini, kepemilikan dan siklus hidupnya cocok, dan salah satu manfaatnya adalah roll-up bawaan.” Jika semantiknya tidak cocok, selesaikan perhitungannya dengan cara lain. Jangan memelintir model data demi mendapatkan sebuah fitur.

Lalu apa cara lainnya? Anda membangun roll-up sendiri: sebuah bidang di induk yang menyimpan nilai hasil perhitungan, dan otomatisasi yang menjaganya tetap mutakhir. Misalkan Mitra Ritel adalah lookup dari Pengiriman, sebagaimana mestinya, dan bisnis ingin melihat Open Deliveries (Pengiriman Terbuka) di mitra. Tambahkan bidang angka, Open Deliveries, ke mitra. Lalu sebuah record-triggered flow, atau trigger Apex ketika volume atau logikanya menuntut kode, menghitungnya ulang setiap kali sebuah pengiriman berubah. Cara ini bekerja lewat lookup, bisa memfilter berdasarkan apa saja, dan bisa memakai tanggal dan formula yang tidak bisa dipakai roll-up bawaan.

Tetapi sekarang Andalah yang bertanggung jawab membuatnya benar, dan di situlah biasanya hal ini salah. Otomatisasinya harus berjalan pada setiap perubahan yang penting: anak baru, anak yang diedit, anak yang dihapus, anak yang dipulihkan, dan anak yang dipindahkan ke induk lain, yang berarti menghitung ulang induk lama maupun induk baru. Ia harus sanggup menangani pemuatan data 200 rekaman sekaligus tanpa menabrak batas. Hitung ulang dari awal, jangan menambah dan mengurangi, supaya satu peristiwa yang terlewat tidak membuat angkanya salah selamanya. Rencanakan cara untuk menghitung ulang semuanya, untuk pemuatan pertama dan untuk hari ketika angkanya melenceng. Dan ingat bahwa setiap penyimpanan anak kini memperbarui induknya, sehingga induk dengan ribuan anak membawa kembali masalah penguncian yang akan kita lihat sebentar lagi. Roll-up bawaan melakukan semua itu untuk Anda; roll-up kustom adalah sepotong kecil perangkat lunak yang menjadi milik Anda.

Tiga Tingkat ke Dalam: Menumpuk Master-Detail

Platform punya bentuk, dan master-detail punya dua dimensi dari bentuk itu. Yang pertama adalah kedalaman.

Anda bisa menumpuk master-detail sampai tiga tingkat detail kustom ke dalam, dan itulah dasarnya (Considerations for Object Relationships (opens in a new tab)). Di kelas saya menggambarnya sebagai sebuah akun dengan pesanan (satu), pesanan dengan item-itemnya (dua), dan item dengan detailnya (tiga), lalu saya mencoba menambahkan tingkat keempat dan Salesforce tidak mengizinkannya. Di Steve Trucking bentuknya mungkin seperti ini: sebuah Pengiriman adalah master; Item Pengiriman-nya adalah tingkat pertama; Tugas Pemasangan (Install Task) sebuah item adalah tingkat kedua; dan Langkah Tugas (Task Step) setiap tugas adalah tingkat ketiga. Tingkat keempat, misalnya Catatan Langkah (Step Note), harus berupa lookup.

Click to enlarge

Beberapa aturan menyertai tumpukan itu:

• Objek standar tidak bisa berada di sisi detail dari objek kustom. Objek kustom bisa menjadi detail dari Akun; Akun tidak bisa menjadi detail dari objek Anda.
• Sebuah objek hanya boleh muncul sekali dalam tumpukan bertingkat. Salesforce tidak ingin Anda berputar kembali ke diri sendiri: sebuah subdetail tidak bisa sekaligus menjadi master dari master-nya sendiri.
• Master tidak bisa langsung me-roll-up tingkat paling bawah. Jika Pengiriman ingin tahu jumlah Langkah Tugas, Tugas Pemasangan me-roll-up langkah-langkahnya, Item Pengiriman me-roll-up hasil roll-up itu, dan Pengiriman me-roll-up item-itemnya: satu tingkat demi satu tingkat.
• Kepemilikan dan berbagi datang dari puncak. Setiap tingkat mewarisi pemilik dan akses dari master.
• Menghapus master menghapus semua yang ada di bawahnya, dan memulihkannya mengembalikan semuanya.

Tiga tingkat biasanya sudah lebih dari cukup. Jika desain Anda terus menginginkan tingkat keempat, tanyakan apakah setiap tingkat benar-benar milik tingkat di atasnya seumur hidupnya. Dan ingat bahwa Anda boleh memilih tautan mana yang memutus rantainya. Tingkat keempat tidak harus menjadi lookup-nya: mungkin sebuah Tugas Pemasangan sebenarnya tidak benar-benar milik Item Pengirimannya, karena ia dijadwalkan dan ditugaskan sendiri, sehingga tautan itu menjadi lookup, dan kini Tugas Pemasangan memulai rantai baru dengan Langkah Tugas dan Catatan Langkah di bawahnya. Pilih tautan di mana anak benar-benar punya hidupnya sendiri, dan jadikan tautan itu lookup.

Click to enlarge

Kini Tugas Pemasangan punya pemiliknya sendiri dan pengaturan berbaginya sendiri, sebuah pengiriman bisa dihapus tanpa ikut menghapus tugas-tugas pemasangannya, dan Tugas Pemasangan bisa punya dua tingkat lagi di bawahnya. Itulah trade-off-nya: rantainya lebih pendek, dan hidup tugas pemasangan menjadi miliknya sendiri.

Dua Induk ke Samping: Junction Object Salesforce

Pertama, sedikit soal istilah, karena “junction object” punya dua arti, dan saya mengajarkan keduanya.

Di bab 2 kita menemukan objek penghubung logis: pertemuan dua gagasan kunci yang menjadi sesuatu yang berdiri sendiri, dengan atributnya sendiri. Seekor anjing mengetahui banyak trik, sebuah trik diketahui banyak anjing, dan Trik Anjing berada di antara keduanya, menyimpan tingkat keterampilan dan tanggalnya. Itulah objek penghubung logis, di model logis, jauh sebelum siapa pun memutuskan lookup atau master-detail.

Salesforce memakai istilah itu secara lebih sempit. Ketika Salesforce menyebut junction object, yang dimaksud adalah objek kustom dengan dua hubungan master-detail (Create a Many-to-Many Object Relationship (opens in a new tab)). Saya akan menyebutnya Junction Object Salesforce (objek penghubung Salesforce). Setiap Junction Object Salesforce adalah objek penghubung logis, tetapi tidak setiap objek penghubung logis menjadi Junction Object Salesforce: bangun satu dengan sebuah master-detail dan sebuah lookup, atau dengan dua lookup, dan ia tetap objek penghubung logis, hanya saja bukan jenis Salesforce. (Salesforce sendiri tidak sepenuhnya konsisten: referensi objeknya menyebut beberapa objek standar yang dibangun di atas lookup sebagai “junction object”. Untuk ujian, anggaplah definisi yang sempit.)

Pengetahuan untuk ujian. Junction Object Salesforce adalah objek kustom dengan dua hubungan master-detail, dan itulah yang dimaksud Salesforce ketika menyebut “junction object”. Objek penghubung logis adalah gagasan pemodelan yang lebih luas: objek apa pun yang menghubungkan dua objek lain dalam hubungan banyak-ke-banyak dan membawa atributnya sendiri, bagaimanapun cara membangunnya.

Dimensi kedua adalah lebar. Bisakah seorang anak punya dua induk master-detail? Bisa. Tiga? Tidak. Setiap objek kustom bisa punya paling banyak dua hubungan master-detail (Considerations for Object Relationships (opens in a new tab)). Dua induk master-detail adalah cara Anda membangun Junction Object Salesforce untuk hubungan banyak-ke-banyak. Kru dan Truk bertemu dalam sebuah Penugasan Kru, dan seperti yang kita temukan di bab 2, itu bukan sekadar pipa: ia punya tanggal, rute, mungkin status. Objek penghubung adalah tempat hubungan menjadi sebuah konsep bisnis. Tips Salesforce untuk membangunnya: beri nama yang mengatakan apa itu, jadikan nama rekamannya penomoran otomatis, dan ganti nama related list setiap master menjadi master yang lain, sehingga halaman Kru menampilkan “Truk” dan halaman Truk menampilkan “Kru” (Create a Many-to-Many Object Relationship (opens in a new tab)).

Inilah seluk-beluknya. Salah satu dari dua induk adalah yang primer, yaitu induk yang bidang master-detail-nya Anda buat lebih dulu. Tidak ada penanda visual mana yang primer, jadi ini pertanyaan ujian klasik, sekaligus kejutan klasik.

Apa yang ditentukan oleh induk primer? Tiga hal (Create a Many-to-Many Object Relationship (opens in a new tab)):

• Tampilan. Halaman-halaman objek penghubung memakai warna dan ikon master primer.
• Pemilik. Rekaman penghubung mewarisi pemilik rekaman master primer. Anda tidak pernah melihatnya, karena detail tidak punya bidang Owner; ini baru penting jika suatu saat Anda menghapus kedua hubungan master-detail.
• Divisi, jika org Anda memakai divisi, dengan cara yang sama.

Dan yang satunya lagi adalah yang sekunder. Apa artinya?

• Ia berikutnya dalam antrean untuk menjadi primer. Hapus bidang master-detail primer atau ubah menjadi lookup, dan yang sekunder menjadi primer.
• Ia menentukan cakupan laporan. Salesforce memberi Anda dua tipe laporan: “Primary master with junction object and secondary master” dan “Secondary master with junction object and primary master”. Master yang disebut lebih dulu menentukan rekaman mana yang bisa ditampilkan laporan.
• Ia sama pentingnya untuk akses. Begini cara saya merumuskannya: kepemilikan dari yang primer, akses dari keduanya, dan yang paling ketat yang menang. Objek penghubung, seperti detail mana pun, tidak punya tabel berbagi sendiri. Salesforce memeriksa akses pengguna ke kedua rekaman master, melalui Sharing Setting di setiap bidang master-detail. Jika keduanya diatur ke Read/Write, pengguna butuh Read/Write pada kru dan pada truk untuk mengedit Penugasan Kru (Considerations for Object Relationships (opens in a new tab)).
• Ia sama kuatnya dalam penghapusan. Hapus salah satu master, kru atau truknya, dan rekaman penghubungnya masuk ke Tempat Sampah. Hapus keduanya dan rekaman itu hilang untuk selamanya.

Click to enlarge

Beberapa aturan lagi: kedua master bisa punya ringkasan roll-up dari objek penghubung, dan formula serta aturan validasi objek penghubung bisa menjangkau bidang di kedua master. Tetapi objek penghubung tidak bisa menjadi master bagi apa pun, jadi ia tidak bisa berada di tengah tumpukan, dan kedua master tidak boleh objek yang sama; hubungan banyak-ke-banyak dari sebuah objek ke dirinya sendiri butuh desain yang berbeda. Dan jika sebuah induk punya lebih dari 200 rekaman penghubung dan objek penghubung itu me-roll-up ke induk yang lain, Salesforce tidak akan mengizinkan Anda menghapus induk tersebut sampai Anda menghapus cukup banyak rekaman penghubungnya.

Jadi: induk mana yang seharusnya primer? Buat lebih dulu induk yang memiliki maknanya. Untuk Penugasan Kru, kru yang melakukan pekerjaannya, jadi saya akan membuat Kru lebih dulu. Lalu tuliskan, karena tidak ada apa pun di layar yang akan memberi tahu orang berikutnya.

Setelah semua itu, saya sendiri tidak berakhir dengan banyak Junction Object Salesforce. Biasanya sebuah objek punya satu induk master-detail, dan jenis datanya sama: data pelanggan di bawah data pelanggan, transaksional di bawah transaksional (ingat jenis-jenis data di bab 2: pelanggan, transaksional, referensi). Ketika induknya yang lain berjenis berbeda, biasanya objek referensi, hubungan itu adalah lookup. Sebuah Item Pengiriman milik Pengirimannya: master-detail, keduanya transaksional. Ia menunjuk ke Produk yang dibawanya dengan lookup, karena produk adalah data referensi dengan hidupnya sendiri, dan tidak ada yang ingin penghapusan sebuah produk ikut menghapus riwayat pengiriman bertahun-tahun. Item Pengiriman tetap objek penghubung logis antara sebuah pengiriman dan produk-produk di dalamnya; ia hanya bukan Junction Object Salesforce.

Hubungan dengan Diri Sendiri: Ketika Garisnya Kembali

Sebuah objek bisa berhubungan dengan dirinya sendiri: akun induk, seorang manajer, pusat distribusi yang melapor ke hub regional. Salesforce sudah menyediakan dua yang akan Anda temui di hampir setiap org: Akun ke Akun, bidang Parent Account (Akun Induk) yang membangun hierarki akun, dan Kasus ke Kasus, Parent Case dari modul 2 yang mengelompokkan kasus-kasus yang terkait. Hubungan dengan diri sendiri harus berupa lookup, dan sebuah rekaman tidak bisa menunjuk ke dirinya sendiri, meskipun dua rekaman bisa saling menunjuk (Considerations for Object Relationships (opens in a new tab)). Di objek User, ini menjadi tipe tersendiri, hubungan hierarkis, yang dipakai untuk hal seperti manajer seorang pengguna. Mekanismenya mudah; penamaannya yang penting. Lookup dari Pusat Distribusi ke Pusat Distribusi yang dinamai Distribution_Center__c tidak membantu siapa pun. Induk? Cadangan? Limpahan? Beri nama hubungannya sesuai perannya, bukan sesuai objek yang ditunjuknya.

Click to enlarge

Hierarkis: Hubungan Khas Objek User

Yang satu ini kecil, dan persis jenis fakta unik yang jarang diketahui yang saya perkirakan akan diangkat dalam ujian. Hierarkis adalah lookup khusus yang ada hanya di objek User. Ia menghubungkan satu pengguna dengan pengguna lain, dan Salesforce tidak membiarkan rantainya berputar kembali: seorang pengguna tidak bisa menunjuk ke dirinya sendiri, secara langsung maupun tidak langsung (Object Relationships Overview (opens in a new tab)). Jika manajer Maria adalah Dev, manajer Dev tidak bisa Maria, atau siapa pun yang melapor ke atas sampai ke Maria.

Itulah bedanya dengan hubungan dengan diri sendiri di atas. Di Akun atau objek kustom, dua rekaman bisa saling menunjuk. Di User, hierarkinya harus tetap menjadi hierarki. Dan inilah satu-satunya cara menghubungkan User ke User: lookup biasa dari User ke dirinya sendiri tidak ditawarkan.

Anda sudah punya satu. Bidang standar Manager di User adalah hubungan hierarkis, dan persetujuan (approval) bisa memakainya: kirim permintaan ini ke manajer pengaju. Anda juga bisa membuat sendiri, misalnya Escalation Contact (Kontak Eskalasi) atau Backup Approver (Pemberi Persetujuan Cadangan), dan persetujuan bisa dirutekan melaluinya dengan cara yang sama (ApprovalProcess, Metadata API (opens in a new tab)). Jangan tertukar dengan hierarki peran, yang menentukan akses rekaman. Bidang hierarkis hanyalah hubungan antarpengguna; ia tidak membagikan satu rekaman pun.

Pengetahuan untuk ujian. Hubungan hierarkis ada hanya di objek User, seperti bidang standar Manager, dan seorang pengguna tidak bisa menunjuk ke dirinya sendiri, secara langsung maupun tidak langsung. Ini bukan hierarki peran.

Hubungan Juga Punya Batasan

Setiap objek bisa punya paling banyak dua hubungan master-detail. Bidang lookup dan master-detail bersama-sama dihitung sebagai bidang hubungan: 40 per objek secara bawaan, paling banyak 50 atas permintaan. Bidang ringkasan roll-up: 25 per objek secara bawaan, paling banyak 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab)). Salesforce menambahkan bahwa menaikkan salah satu batas itu bisa memengaruhi kinerja.

Anda tidak perlu merancang sesuai angka-angka itu; Anda perlu menyadari ketika Anda sudah mendekatinya. Objek dengan hubungan demi hubungan yang bergantung padanya sedang memberi tahu Anda sesuatu. Mungkin ia memang sesentral itu. Atau mungkin modelnya salah. (Dan aturan ruang cadangan dari bab 18 berlaku: tetaplah jauh di bawah batas, diukur terhadap kondisi tahun ketiga.)

Pertanyaan 10.000 Anak

Lalu ada induk dengan terlalu banyak anak. Panduan Salesforce sendiri adalah tidak melebihi sekitar 10.000 rekaman anak untuk satu induk master-detail (Considerations for Object Relationships (opens in a new tab)), dan panduannya tentang akses rekaman dalam skala besar mengatakan hal yang sama untuk hubungan induk-anak secara umum (Parent-Child Data Skew (opens in a new tab)). Rekaman ke-10.001 tidak merusak org. Tetapi melewati titik itu, menyimpan seorang anak bisa mengunci induknya, dan perubahan berbagi pada induk merambat ke setiap anak.

Jadi ketika saya melihat satu induk, dengan anak dalam jumlah sangat besar, saya bertanya: mengapa semuanya berada di bawah induk yang sama, siapa pemiliknya, bagaimana mereka dikueri, dan otomatisasi apa yang menyentuh induknya? Setiap pengiriman di bawah satu akun “Steve Trucking” akan melewati 10.000 dalam beberapa hari. Hubungan satu-ke-banyak yang polos berubah menjadi masalah skew. Modul berikutnya memberi gambaran awal tentang skew, dan Bagian 2 membahasnya secara mendalam.

Jangan Merancang Garisnya Berdasarkan Fitur

Inilah kebiasaan yang saya inginkan dari modul ini. Jangan memulai dari “saya butuh roll-up,” “saya butuh ini wajib,” “saya ingin pengaturan berbagi yang diwarisi.” Itu petunjuk implementasi. Mulailah dari bisnisnya: apakah anak punya hidupnya sendiri, siapa pemiliknya, bisakah ia berdiri sendiri, bisakah ia pindah, apa yang terjadi ketika induknya hilang, apakah hubungan itu membawa data, dan seberapa besar setiap sisi bisa tumbuh? Lalu pilih hubungan yang mengimplementasikan jawaban-jawaban itu.

Click to enlarge

Di luar ujian: apa yang diubah AI. AI bisa mengusulkan hubungan dalam hitungan detik. AI tidak bisa memberi tahu Anda apakah bisnis akan pernah menghapus induknya. Membuat diagram lebih cepat tidak membuat hubungan yang salah lebih murah untuk dibatalkan begitu jutaan rekaman dan puluhan otomatisasi bergantung padanya.

Yang Diputuskan Arsitek di Sini

• Apakah anak punya siklus hidupnya sendiri atau benar-benar milik induknya, dan apakah kepemilikan dan aksesnya miliknya sendiri atau diwarisi.
• Apakah anak bisa ada tanpa induk, berpindah antarinduk, atau bertahan dari penghapusan induknya.
• Apa yang dilakukan setiap lookup ketika induknya dihapus: kosongkan, blokir, atau hapus berantai.
• Apakah hubungan banyak-ke-banyak hanyalah pipa atau sebuah konsep bisnis, apakah objek penghubung logis menjadi Junction Object Salesforce, induk mana yang primer, dan apa arti kedua induk itu bagi akses.
• Apakah model cocok dengan bentuk platform: tiga tingkat detail kustom ke dalam, dua induk master-detail ke samping, batasan hubungan dan roll-up.
• Apakah jumlah dan sebaran anak yang diharapkan menimbulkan risiko skew yang seharusnya mengubah desainnya.

Hubungan adalah sekumpulan janji tentang bagaimana dua potongan data berperilaku bersama. Buatlah janji itu dengan sengaja.

Jelajahi

• Bantuan Salesforce, Considerations for Object Relationships (opens in a new tab), dicek 2026-10-13 (bahasa Inggris).
• Bantuan Salesforce, Object Relationships Overview (opens in a new tab) dan Create a Many-to-Many Object Relationship (opens in a new tab), dicek 2026-10-13 (bahasa Inggris).
• Bantuan Salesforce, Roll-Up Summary Field (opens in a new tab), dicek 2026-10-13 (bahasa Inggris).
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab), dicek 2026-10-13 (bahasa Inggris).
• Bantuan Salesforce, Lookup Filters (opens in a new tab), dicek 2026-10-13 (bahasa Inggris).
• Bantuan Salesforce, Increase the Maximum Relationships Allowed per Object (opens in a new tab) dan Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab), dicek 2026-10-02 (bahasa Inggris).
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab), dicek 2026-10-02 (bahasa Inggris).