Lewati ke konten
SteveTechArcSteveTechArc Courses

Kepemilikan dan Siklus Hidup

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)

The cut end of a large log in a forest, every year's growth ring visible from the center to the bark.
Gambar dibuat dengan AI

Modul 8 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Hubungan Punya Konsekuensi · Berikutnya: Menjaga Data Tetap Konsisten

Pertanyaan yang dijawab modul ini: Siapa pemilik rekamannya, dan apa yang terjadi padanya sepanjang hidupnya?

Saat melihat sebuah model data, saya tidak hanya ingin tahu apa saja objeknya dan bagaimana semuanya terhubung. Saya ingin tahu apa yang terjadi pada rekaman-rekamannya dari waktu ke waktu. Siapa yang membuatnya? Siapa pemiliknya? Siapa yang bisa menugaskannya ulang? Apa yang terjadi ketika hubungan bisnis berubah, ketika rekaman tidak lagi aktif? Haruskah rekaman itu pernah dihapus, dan berapa lama kita menyimpannya? Tidak satu pun dari itu muncul di ERD, diagram hubungan entitas (entity relationship diagram): kotak-kotak dan garis-garis model data di bab 2. Semuanya adalah arsitektur data. Dan di Salesforce, kepemilikan adalah tempat model data dan model keamanan saling bertemu.

Kepemilikan Lebih dari Sekadar Nama di Sebuah Bidang

Section titled “Kepemilikan Lebih dari Sekadar Nama di Sebuah Bidang ”

Admin melihat Owner di sebuah rekaman dan membacanya sebagai label: Bart memiliki akun ini, Lisa memiliki kasus itu. Bisa saja artinya begitu. Tetapi di Salesforce, kepemilikan juga merupakan mekanisme platform. Pada objek yang punya pemilik, pemilik menentukan siapa yang bisa melihat rekaman melalui hierarki peran, aturan berbagi, antrean, dan penugasan ulang. Jadi ketika saya bertanya “siapa pemilik rekaman ini?” saya tidak menanyakan nama siapa yang tercantum di halaman. Saya bertanya perilaku keamanan dan siklus hidup apa yang kita lekatkan padanya. Pemiliknya bisa seorang pengguna, atau untuk sebagian objek, di antaranya objek kustom, kasus, dan prospek, sebuah antrean, dan bagaimanapun juga pemilik mendapat akses penuh ke rekaman itu (Understanding Sharing (opens in a new tab)).

Itulah sebabnya saya memisahkan tanggung jawab bisnis dari kepemilikan rekaman. Kadang keduanya orang yang sama. Kadang tidak. Jika bisnis bilang seorang dispatcher bertanggung jawab atas sebuah pengiriman, itu tidak otomatis menjadikan dispatcher itu pemiliknya. Tanggung jawab bisa tinggal di bidangnya sendiri sementara kepemilikan diatur untuk mendukung keamanan dan skala. Jangan biarkan keduanya tercampur hanya karena sama-sama memakai kata “pemilik.”

Tabel Berbagi: Tempat Kepemilikan Menjadi Akses

Section titled “Tabel Berbagi: Tempat Kepemilikan Menjadi Akses ”

Sebagian orang bahkan tidak tahu apa itu tabel berbagi (share table). Setiap arsitek data seharusnya tahu.

Sebagian besar pengaturan berbagi sebuah rekaman disimpan di objek berbagi (share object) yang terkait, versi Salesforce dari daftar kontrol akses (access control list) (Understanding Sharing (opens in a new tab)). Akun punya AccountShare, Kontak punya ContactShare, dan objek kustom mendapat miliknya sendiri: Truck__c punya Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Setiap barisnya mengatakan empat hal:

  • Rekaman yang mana: ID induknya (parent ID).
  • Siapa: seorang pengguna, atau sebuah grup (grup publik, grup sebuah peran, sebuah teritori).
  • Seberapa banyak: Read, Edit, atau All (akses penuh).
  • Mengapa: row cause-nya. Owner untuk pemilik, Rule untuk aturan berbagi, Manual untuk berbagi manual, Team, penyebab implisit yang ditambahkan Salesforce antara sebuah akun dan anak-anaknya, serta alasan yang didefinisikan developer untuk berbagi Apex.

Di kelas saya membuka Workbench dan mengueri tabel berbagi sambil membagikan sebuah rekaman, dan Anda melihat baris-barisnya muncul dan menghilang. Ketika seseorang bertanya “kenapa orang ini bisa melihat itu?”, jawabannya sering ada di sebuah baris, lengkap dengan alasannya.

Tetapi tidak semuanya ada di situ. Organization-wide default bukan sebuah baris. Hierarki peran juga tidak disimpan di sana: akses untuk orang-orang di atas pemilik dihitung saat dibutuhkan. Dan View All, Modify All, View All Data, serta Modify All Data sama sekali melewati tabel berbagi (Sharing a Record Using Apex (opens in a new tab)). Seperti yang saya katakan di kelas: centang View All dan Anda sudah melewati tabel berbagi.

Salesforce juga membagikan sebagian rekaman untuk Anda, karena cara rekaman-rekaman itu saling terkait. Ini disebut berbagi implisit, dan ia bekerja antara sebuah akun dan anak-anaknya. Jika Anda bisa melihat sebuah kontak, kasus, atau peluang, Anda juga bisa membaca akun tempatnya berada. Dan pemilik akun mendapat akses ke kontak, kasus, dan peluang akun itu, pada tingkat yang ditentukan oleh peran pemiliknya (Implicit Sharing (opens in a new tab)). Pada rilis-rilis terbaru, Salesforce menghitung sebagian akses anak itu saat dibutuhkan alih-alih menyimpannya sebagai baris, jadi jangan heran jika kueri terhadap tabel berbagi tidak menampilkannya. Saya hanya memberi petunjuk di sini; detailnya ada di Hubungan dan Berbagi Bawaan.

Satu pengecualian lagi, untuk ketika Anda punya banyak pengguna eksternal. Pengguna komunitas bervolume tinggi (high-volume community users), lisensi Customer Community yang dibangun untuk ribuan hingga jutaan pelanggan, tidak punya peran, tidak bisa berada di grup publik, dan tidak bisa diberi rekaman melalui aturan berbagi atau berbagi manual (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). Bagi mereka, tabel berbagi bukan jawabannya: mereka menjangkau rekaman melalui set berbagi, yang mencocokkan akun atau kontak sebuah rekaman dengan milik pengguna itu sendiri. Itu salah satu alasan lisensi tersebut bisa berskala besar. Kursus Sharing and Visibility membahasnya di Berbagi dengan Pengguna Eksternal.

Dan ingat modul 7: objek detail sama sekali tidak punya objek berbagi. Aksesnya datang dari objek berbagi master dan Sharing Setting di bidang master-detail.

Mengapa arsitek data peduli? Karena kepemilikan ditulis ke dalam tabel ini. Setiap pergantian pemilik, setiap aturan berbagi baru, setiap pengguna yang berpindah peran atau grup berarti Salesforce menambah dan menghapus baris. Pada beberapa ribu rekaman tidak ada yang menyadarinya. Pada sepuluh juta, dengan satu pengguna yang memiliki sebagian besarnya, itulah perhitungan ulang yang akan kita temui sebentar lagi.

Pengetahuan untuk ujian. Objek berbagi untuk objek kustom dinamai Object__Share, seperti Truck__Share. Objek detail tidak punya objek berbagi: aksesnya datang dari master. Dan ketika pemilik sebuah rekaman berganti, berbagi manualnya dihapus, sedangkan berbagi Apex dengan alasan buatan developer tetap ada.

Di sinilah model data menyerahkan tongkat estafet ke model keamanan, dan sisanya saya ajarkan di kursus Sharing and Visibility Architect: 22 Cara Berbagi Rekaman ala Steve, Org-Wide Defaults, Kepemilikan, Antrean, dan Hierarki Peran, Hubungan dan Berbagi Bawaan untuk berbagi implisit, dan Berbagi Terprogram dan Kode yang Aman untuk alasan berbagi Apex. Di kursus ini, bab 12 menyatukan semuanya untuk manusia, aplikasi, dan agen.

Kadang Kepemilikan Diwarisi

Section titled “Kadang Kepemilikan Diwarisi ”

Di modul sebelumnya kita melihat bahwa anak master-detail tidak punya pemiliknya sendiri; ia mengikuti induknya. Itu sering kali persis tepat. Apakah bisnis butuh pemilik yang berbeda untuk setiap item di sebuah pengiriman? Tidak. Pengiriman memiliki siklus hidupnya dan item menjadi bagian darinya. Inilah sebabnya desain hubungan dan desain kepemilikan terjadi bersama-sama: ketika Anda memilih master-detail, Anda sudah mengambil sebagian keputusan kepemilikan.

Siapa Pemilik Rekaman yang Dibuat Sistem?

Section titled “Siapa Pemilik Rekaman yang Dibuat Sistem? ”

Sekarang mulai menarik. Seseorang membuat sebuah akun, dan mungkin ia menjadi pemiliknya. Tetapi sebuah ERP mengirim 100.000 transaksi dalam semalam. Siapa pemilik semua itu? Pengguna integrasi? Sebuah antrean? Pemilik regional yang ditentukan dari datanya? Akun sistem yang tidak dipikirkan siapa pun selama lima tahun? Dan kini agen juga membuat rekaman.

Posisi saya: tergantung apakah kepemilikan penting untuk berbagi. Pengguna integrasi, atau pengguna agen, adalah pengguna yang sah, dan ia boleh memiliki rekaman. Jika kepemilikan menentukan akses di objek itu (melalui hierarki peran atau aturan berbagi), tugaskan rekamannya ke pemilik yang tepat: pengguna nyata, antrean, atau pengguna pemilik khusus. Jika tidak, mempertahankan pengguna sistem sebagai pemilik mungkin pilihan yang lebih baik, karena dengan begitu jejak audit langsung mengarah kembali ke apa pun yang membuat rekaman itu.

Apa pun pilihannya, putuskan dengan sengaja. Akun integrasi yang memiliki segalanya diam-diam telah menjadi bagian dari arsitektur keamanan Anda, dan seseorang perlu tahu apa yang terjadi jika akun itu suatu saat dinonaktifkan.

Kepemilikan Bisa Menjadi Masalah Skala

Section titled “Kepemilikan Bisa Menjadi Masalah Skala ”

Sebarannya juga penting. Sepuluh juta rekaman yang tersebar di ribuan pemilik adalah satu bentuk. Sepuluh juta rekaman yang dimiliki satu pengguna adalah bentuk yang sangat berbeda. Salesforce menyebutnya ownership data skew ketika satu pengguna memiliki lebih dari 10.000 rekaman sebuah objek (Ownership Data Skew (opens in a new tab)). Biasanya ini terjadi ketika seseorang memarkir semuanya pada satu pengguna atau antrean: semua prospek yang belum ditugaskan pada pengguna penampung, setiap rekaman integrasi pada pengguna integrasi. Tidak berbahaya sampai pengguna itu berpindah posisi di hierarki peran, atau masuk atau keluar dari grup yang menjadi tumpuan sebuah aturan berbagi. Lalu Salesforce harus menyesuaikan entri berbagi dalam jumlah sangat besar, dan Anda mendapat perhitungan ulang yang berjalan lama.

Panduannya praktis. Sebarkan kepemilikan ke lebih banyak pengguna jika memungkinkan. Jika satu pengguna harus memiliki banyak rekaman, jauhkan ia dari hierarki peran; jika ia butuh peran, taruh ia di peran tersendiri di puncak dan jangan dipindahkan, dan jauhkan ia dari grup publik yang dipakai aturan berbagi (Ownership Data Skew (opens in a new tab)). Cara berpikir yang sama berlaku untuk induk dengan terlalu banyak anak dari modul sebelumnya, parent-child skew.

Jadi sebaran adalah bagian dari model fisik. Jangan hanya bertanya berapa banyak rekamannya; tanyakan bagaimana sebarannya. Ini versi lain dari Jumlah Nol: bukan hanya berapa banyak nolnya, tetapi di mana nol-nol itu terkonsentrasi. Bagian 2 membahas skew secara mendalam; di sini saya ingin Anda melihatnya datang. Kursus Sharing and Visibility membahasnya lagi di Berbagi dalam Skala Besar.

“Pemilik Bawaan” Menjadi Arsitektur

Section titled ““Pemilik Bawaan” Menjadi Arsitektur ”

Inilah pola yang terus-menerus saya lihat. Tidak ada yang tahu siapa yang seharusnya memiliki sesuatu, jadi seseorang berkata, “Tugaskan saja semuanya ke pengguna integrasi,” atau “buat pengguna generik bernama System.” Mungkin itu tepat. Tetapi jangan melakukannya secara kebetulan. Pengaturan bawaan sementara punya kebiasaan menjadi permanen: dua tahun kemudian setiap rekaman milik integration@company.com, tidak ada yang ingat alasannya, dan mengubahnya menjadi sebuah proyek. Itulah Uji Reversibilitas dari bab 1: sebelum Anda memberikan satu juta rekaman kepada satu pemilik, tanyakan apa yang dibutuhkan untuk mengubahnya nanti.

Penugasan Ulang Adalah Peristiwa Siklus Hidup

Section titled “Penugasan Ulang Adalah Peristiwa Siklus Hidup ”

Pemilik berganti. Sales keluar, teritori bergeser, tim direorganisasi, wilayah diseimbangkan ulang. Apa yang bergantung pada pemilik: berbagi, otomatisasi, laporan, antrean, eskalasi, integrasi? Jika mengganti pemilik mengubah siapa yang bisa melihat rekaman, penugasan ulang bukanlah urusan beres-beres admin. Itu peristiwa keamanan, dan pada satu juta rekaman itu juga peristiwa operasional. Perhatikan tabel berbagi saat hal itu terjadi: berbagi manual dihapus ketika pemilik berganti, sedangkan berbagi Apex dengan alasan buatan developer tetap bertahan (Understanding Sharing (opens in a new tab)). Di kelas saya membagikan sebuah rekaman kepada seseorang, mengganti pemiliknya, dan orang itu kehilangan akses. Seisi ruangan selalu terkejut.

Dan ingat bahwa kepemilikan tidak sama dengan akses. Pemilik bukan satu-satunya orang yang perlu melihat sebuah rekaman, dan Salesforce punya banyak cara untuk memberi akses: hierarki peran, aturan berbagi, tim, teritori, berbagi manual dan terprogram. Kursus Sharing and Visibility membahasnya secara mendalam, dimulai dengan 22 Cara Berbagi Rekaman ala Steve. Poin arsiteknya lebih sederhana: jangan memakai kepemilikan untuk menyelesaikan setiap masalah akses. Jika Anda memindah-mindahkan pemilik hanya agar seseorang bisa melihat sebuah rekaman, kemungkinan besar Anda sedang menyelesaikan masalah yang salah.

Pembuatan Hanyalah Awalnya

Section titled “Pembuatan Hanyalah Awalnya ”

Banyak pemodelan data berhenti di pembuatan: bidangnya, objeknya, hubungannya, selesai. Tetapi rekaman itu mungkin hidup sepuluh tahun. Ia diperbarui, berganti pemilik, berganti status dan hubungan, menjadi tidak aktif, menjadi riwayat, mungkin perlu diarsipkan, dan suatu hari mungkin dihapus. Arsitektur bukan hanya tentang bagaimana rekaman lahir. Arsitektur adalah apa yang terjadi dari lahir sampai mati.

Hidup sebuah rekaman Hidup sebuah rekaman dalam enam tahap, dihubungkan oleh panah. Dibuat: siapa pemiliknya, dan siapa yang melihatnya? Aktif: otomatisasi apa yang berjalan? Ditugaskan ulang: siapa yang mendapat atau kehilangan akses? Tidak aktif: apakah masih dibutuhkan untuk riwayat? Diarsipkan: ke mana perginya, dan apakah masih bisa ditemukan? Dihapus atau disimpan: apa kata aturan retensinya? Di bagian bawah: arsitektur bukan hanya soal bagaimana rekaman lahir; melainkan apa yang terjadi dari lahir hingga mati. Dibuat Siapa pemiliknya? Siapa yang melihatnya? Aktif Otomatisasi apa yang berjalan? Ditugaskan ulang Siapa yang mendapat atau kehilangan akses? Tidak aktif Masih dibutuhkan untuk riwayat? Diarsipkan Di mana, dan masih bisa ditemukan? Dihapus atau disimpan Apa kata kebijakan retensi? Arsitektur bukan hanya soal bagaimana rekaman lahir. Melainkan apa yang terjadi dari lahir hingga mati. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Jangan Menghapus Hanya karena Sesuatu Sudah Tua

Section titled “Jangan Menghapus Hanya karena Sesuatu Sudah Tua ”

Sebuah Mitra Ritel berhenti mengirim pekerjaan. Hapus akunnya? Tidak otomatis: pengiriman, klaim, dan riwayat penagihannya masih penting. Sebuah truk dipensiunkan. Hapus truk itu, beserta riwayat pengiriman dan klaim kerusakannya? Bendanya mungkin sudah tidak aktif, tetapi datanya masih. Jadi saya memisahkan tidak aktif dari hilang. Truk yang dipensiunkan bisa tetap ada di model; mantan karyawan masih bisa muncul di riwayat audit. Arsitektur harus menyimpan fakta-fakta yang penting setelah hubungan operasionalnya berakhir.

Retensi Adalah Persyaratan Bisnis

Section titled “Retensi Adalah Persyaratan Bisnis ”

Sisi lainnya: menyimpan segalanya selamanya juga bukan arsitektur. Penyimpanan bertambah, laporan melambat, pencarian makin bising, dan hukum privasi mungkin mengharuskan sebagian data dihapus. Jadi saya ingin jawaban yang eksplisit untuk berapa lama kita menyimpan ini? “Salesforce menyimpannya” bukanlah kebijakan retensi.

Dan sebagian besar, ini pertanyaan tentang data transaksional. Data referensi, yaitu produk, tipe layanan, pusat distribusi, tidak membengkak, dan rekaman lain menunjuk kepadanya, jadi biasanya data itu tetap disimpan. Data pelanggan ada di tengah-tengah: mungkin akan tiba harinya Anda mengakhiri siklus hidup seorang pelanggan, terutama ketika Anda menyimpan data pribadi dan alasan untuk menyimpannya sudah habis. Tetapi volumenya ada di transaksi: pengiriman, pesanan, kasus, janji temu, yang dibuat setiap hari, selamanya. Itulah yang tumbuh menjadi ratusan juta baris, dan di situlah retensi harus eksplisit: mungkin dua tahun data operasional di org, tujuh tahun catatan keuangan di suatu tempat, sembilan puluh hari untuk sebagian foto. Itu semua aturan bisnis, dan jika belum ada yang menanyakannya, arsiteklah yang seharusnya bertanya.

Saya sudah bertahun-tahun mengatakannya di kelas: jika Anda tidak mengarsipkan hari ini, apakah Anda akan pernah mengarsipkan? “Nanti kita urus” punya kebiasaan berubah menjadi proyek darurat di tiga ratus juta rekaman. Bagian 2 punya satu modul penuh tentang pengarsipan dan penghapusan permanen, yang dibangun di atas pertanyaan yang sama.

Steve Trucking: Siapa Pemilik Sebuah Pengiriman?

Section titled “Steve Trucking: Siapa Pemilik Sebuah Pengiriman? ”

Sebuah pengiriman dibuat dari manifes Mitra Ritel, oleh sebuah integrasi, sekitar 3.300 kali sehari. Siapa pemiliknya? Bukan Mitra Ritel; itu hubungan bisnis. Bukan Penerima. Kru yang menjalankannya, tetapi haruskah rekaman berganti pemilik setiap kali kru bertukar truk? Dispatcher? Pusat distribusi? Sebuah antrean? Pengguna integrasi yang membuatnya?

Sekarang terapkan modul ini, dimulai dari pertanyaan yang menentukannya: apakah kepemilikan menentukan akses siapa pun ke pengiriman? Di Steve Trucking, tidak. Dispatcher melihat pengiriman untuk pusat distribusinya, kru melihat pengiriman di rute mereka, dan setiap peritel melihat miliknya sendiri di portal mitra. Tidak satu pun dari itu bergantung pada siapa pemilik rekamannya; semuanya datang dari pusat distribusi, rute, dan mitranya.

Jadi jawaban saya: pengguna integrasi memiliki pengiriman-pengirimannya. Ini contoh yang baik tentang pengguna sistem yang memiliki rekaman secara sengaja:

  • Jejak auditnya jujur. Pemilik setiap pengiriman mengatakan dari mana asalnya: integrasi manifes.
  • Akses datang dari berbagi, bukan dari kepemilikan. Aturan berbagi berbasis kriteria pada pusat distribusi memberi tim setiap DC pengiriman-pengirimannya; mitra menjangkau milik mereka melalui portal.
  • Skew dihilangkan lewat desain. Dengan 3.300 per hari, pengguna integrasi melewati 10.000 pengiriman dalam tiga hari, jadi ini ownership skew sejak hari pertama, dan itu tidak apa-apa jika kita merencanakannya. Pengguna integrasi tidak punya peran, sehingga tidak ada apa pun di atasnya dalam hierarki yang harus dihitung ulang, dan ia dijauhkan dari grup publik yang dipakai aturan berbagi kita.
  • Tidak ada yang menugaskan ulang pengiriman. Kru bertukar truk dan dispatcher berganti sif, dan pemiliknya tidak pernah berpindah, jadi tidak ada badai penugasan ulang dan tidak ada berbagi manual yang hilang.

Dan tuliskan apa yang terjadi jika pengguna itu suatu saat dinonaktifkan atau diganti, karena ia kini memiliki jutaan rekaman. Itulah keputusan yang perlu ditemukan oleh tim berikutnya.

Di luar ujian: apa yang diubah AI. Agen membuat dan mengubah rekaman dengan kecepatan mesin. Jika sebuah agen membuat 100.000 rekaman dengan penggunanya sendiri, “nanti kita perbaiki pemiliknya” menjadi skew, perhitungan ulang berbagi, dan proyek pembersihan. Putuskan aturan kepemilikan agen sebelum ia go-live, dengan pertanyaan yang sama: apakah kepemilikan penting untuk berbagi di sini?

Yang Diputuskan Arsitek di Sini

Section titled “Yang Diputuskan Arsitek di Sini ”
  • Apakah kepemilikan mewakili tanggung jawab bisnis, mekanisme keamanan, atau keduanya, dan di mana tanggung jawab tinggal jika bukan di Owner.
  • Apakah rekaman butuh pemiliknya sendiri atau sebaiknya mewarisinya dari induk.
  • Siapa pemilik rekaman yang dibuat integrasi dan agen, tergantung apakah kepemilikan menentukan berbagi.
  • Bagaimana kepemilikan tersebar, dan bagaimana menghindari ownership skew ketika satu pengguna harus memiliki banyak rekaman.
  • Kapan rekaman menjadi tidak aktif, kapan diarsipkan, berapa lama disimpan, dan kapan penghapusan itu tepat.

Ketika Anda melihat sebuah model fisik, jangan hanya bertanya di mana data disimpan. Tanyakan siapa pemiliknya hari ini, siapa yang mungkin memilikinya besok, dan apa yang terjadi ketika kita tidak lagi membutuhkannya. Berikutnya: bahkan dengan objek, bidang, hubungan, dan pemilik yang tepat, data tetap harus bisa dipercaya.

Jelajahi

Section titled “Jelajahi ”