Ketika Volume Bertemu Model Berbagi

🌐 Juga tersedia dalam 19 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris Bagian ini telah berubah dalam bahasa Inggris dan belum diterjemahkan ulang. (35)

Modul 3 dari 4 dalam bab Merancang untuk Skala, bab 7 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Titik Panas: Skew Kepemilikan, Induk, dan Lookup · Berikutnya: Jika Anda Tidak Mengarsipkan Hari Ini…

Pertanyaan yang dijawab modul ini: Bagaimana model yang menghormati berbagi tetap cepat pada volume besar?

Modul sebelumnya menemukan titik panas. Sekarang tambahkan keamanan, tempat arsitektur data yang tampak wajar menjadi mahal. Sembilan juta perintah kerja adalah masalah volume. Sembilan juta perintah kerja yang masing-masing terlihat oleh tepat pengguna internal yang benar dan tepat Mitra Ritel yang benar adalah masalah berbagi dalam volume besar. Sebuah rekaman tidak hanya disimpan; Salesforce juga harus menjawab siapa yang bisa melihatnya? Dalam skala besar, jawaban itu bagian dari arsitektur data.

Berbagi Juga Data

Ketika arsitek menghitung volume, mereka menghitung rekaman bisnis. Tetapi Salesforce juga memelihara apa yang menopang akses: pemilik, peran, grup, aturan berbagi, berbagi eksplisit, keanggotaan. Pada skala kecil Anda bisa lupa pekerjaan itu ada. Pada skala besar Anda tidak bisa. Itulah sebabnya saya tidak pernah berkata “tim keamanan akan mengurus berbagi nanti.” Hubungan yang saya pilih, pemiliknya, induknya, model pengguna eksternalnya: masing-masing memengaruhi berbagi. Arsitek data dan arsitek berbagi mungkin orang yang berbeda, tetapi arsitektur mereka saling terhubung.

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing (terbuka di tab baru); Sharing a Record Using Apex (terbuka di tab baru)). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood (terbuka di tab baru), Winter ‘27, archived copy (terbuka di tab baru)). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables. ⟲

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare (terbuka di tab baru)). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects. ⟲

Klik untuk memperbesar

Step 1 of 3: the records. Nine million work orders. ⟲

Klik untuk memperbesar

Step 2 of 3: the share table, three rules to groups. ⟲

Klik untuk memperbesar

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records. ⟲

That’s why the levers that keep sharing fast are mostly levers on the number of rows: ⟲

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source). ⟲
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs). ⟲
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3). ⟲
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below). ⟲

Test knowledge. Know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. ⟲

Mulailah dari Kebutuhan Akses

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect. ⟲

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together. ⟲

Hierarki Peran Bukan Bagan Organisasi

Tim merancang hierarki peran agar mencerminkan bagan organisasi. Lalu perusahaan melakukan reorganisasi, seseorang memindahkan sebuah peran, dan Salesforce harus menghitung konsekuensi aksesnya. Pada skala kecil tidak ada yang sadar. Pada jutaan rekaman, reorganisasi adalah operasi data yang besar. Itulah sebabnya panduan untuk pemilik bervolume tinggi adalah tanpa peran, atau peran tersendiri yang stabil di puncak hierarki (Ownership Data Skew (terbuka di tab baru)). Prinsipnya bisa diperluas: dalam skala besar, stabilitas adalah fitur desain. Makin banyak rekaman yang bergantung pada sebuah struktur berbagi, makin hati-hati Anda mengubahnya.

Grup juga begitu. Grup publik mengisi aturan berbagi; pengguna termasuk dalam grup; grup berisi grup. Alat yang berguna, tetapi jika populasi besar pengguna dan rekaman bergantung pada keanggotaan grup yang terus berubah, Anda perlu memahami penghitungan ulangnya. Itulah sebabnya pemilik bervolume tinggi dijauhkan dari grup publik yang dipakai sebagai sumber aturan berbagi (sumber yang sama). Pelajarannya bukan “grup publik itu buruk”. Pelajarannya: jangan hubungkan konsentrasi rekaman terbesar Anda ke struktur akses yang paling mudah berubah tanpa memikirkannya matang-matang.

Penghitungan Ulang Berbagi Adalah Pekerjaan Nyata

Steve Trucking mengubah model operasinya: ratusan pengguna berpindah, kepemilikan berubah, peran dan grup berubah, sebuah aturan berbagi besar berubah. Kedengarannya seperti konfigurasi. Tetapi platform mungkin harus menghitung ulang akses di populasi rekaman yang besar, jadi saya memperlakukannya sebagai operasi data. Berapa banyak pengguna, rekaman, perubahan kepemilikan dan keanggotaan? Berapa banyak penghitungan ulang? Bisakah kita mengujinya pada volume nyata? Kapan dijalankan, dan apa yang dilihat pengguna selama itu? Penataan ulang keamanan yang besar layak mendapat disiplin yang sama dengan migrasi data yang besar.

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance (terbuka di tab baru)). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale (terbuka di tab baru), Winter ‘27). ⟲

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time. ⟲

Klik untuk memperbesar

At scale, access realignment is a data operation. ⟲

“Ditunda” tidak berarti santai. Jika sebuah perubahan cukup besar untuk menunda berbagi, saya ingin rencana: diuji pada volume yang realistis, jendela pemeliharaan yang disetujui bisnis, verifikasi, cadangan rencana jika tidak selesai, dan pemahaman tentang apa yang dialami pengguna selama itu. Panduan Salesforce adalah memodelkannya dulu di sandbox salinan penuh (full copy sandbox; sumber yang sama), karena model keamanan yang berjalan indah dengan 5.000 rekaman uji tidak membuktikan apa pun tentang 50 juta. Uji Jumlah Nol yang benar-benar Anda rancang.

Penguncian Granular Membantu, tetapi Bukan Obat

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking (terbuka di tab baru)); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters. ⟲

Steve Trucking: Isolasi Mitra dalam Skala Besar

Di Checkpoint 1, setiap perintah kerja membawa Mitra Ritelnya secara permanen, karena isolasi mitra adalah kebutuhan. Angka skalanya membuat hal itu makin penting, bukan makin kurang: jika Redrock mencakup 40% bisnis, itu berarti sekitar 3,6 juta perintah kerja Redrock dalam lima tahun. Hubungannya benar; Redrock memang satu mitra. Jadi desain akses harus mengikuti hubungan bisnis yang nyata (pengguna mitra melihat perintah kerja mitranya, manajer DC hanya milik DC-nya) alih-alih mendistorsi model. Struktur akun anak per DC dari modul sebelumnya membantu dua kali di sini: ia menyebar anak-anaknya, dan memberi akses tingkat DC sesuatu yang nyata untuk dijadikan pegangan.

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times. ⟲

Akses Internal Berbeda Lagi

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

Kadang keamanan harus mengubah model. Ketika dua jenis informasi punya pemilik, siklus hidup, audiens, atau kebutuhan berbagi yang sama sekali berbeda, Anda bisa menumpuk kontrol tingkat bidang di satu rekaman, atau memisahkan data ke objeknya sendiri dengan batasnya sendiri. Saya tidak memisahkan hanya demi menghindari konfigurasi keamanan tingkat bidang, tetapi keamanan adalah alasan yang sah untuk mengubah model fisik.

Berbagi Punya Jumlah Nolnya Sendiri

Dua desain dengan masing-masing 10 juta rekaman: satu dengan kepemilikan sederhana, hierarki stabil, sedikit aturan berbagi, dan sedikit perubahan keanggotaan; yang lain dengan kepemilikan sangat tersebar, peran yang sering berubah, grup besar bersarang, banyak aturan berbagi, dan reorganisasi terus-menerus. Jumlah rekaman sama, masalah skala sama sekali berbeda. Jadi untuk setiap objek bervolume tinggi, saya juga ingin angka model aksesnya: berapa banyak pemilik dan seberapa terpusat, akses bawaan, hubungan hierarki, aturan, dan grup mana yang berpengaruh, berapa banyak pengguna eksternal, dan apa yang terjadi ketika seseorang berganti peran, mitra ditambahkan, atau sebuah wilayah direorganisasi. Lalu satu pertanyaan: apa penghitungan ulang terbesar yang bisa ditimbulkan desain ini? Itulah skenario yang ingin saya uji.

Klik untuk memperbesar

Count the access model, not just the records. ⟲

Jangan Mengorbankan Keamanan demi Optimasi

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy. ⟲

Di luar ujian: apa yang diubah AI. Agen mengambil dan menggabungkan data lebih cepat daripada siapa pun, yang membuat model akses yang terlalu luas makin berbahaya. Jangan mengandalkan prompt yang berbunyi “jangan tunjukkan data Brightwave kepada Redrock.” Batasnya tempatnya di arsitektur: otorisasi yang harus membatasi apa yang bisa dijangkau agen, bukan instruksi tentang apa yang dipilihnya untuk diungkapkan. Skalakan model otorisasi bersama model data.

Yang Diputuskan Arsitek di Sini

• Hubungan, pemilik, peran, grup, dan aturan berbagi mana yang menggerakkan akses untuk setiap objek bervolume tinggi.
• Apakah pemilik bervolume tinggi dan titik panas lainnya diisolasi dari struktur hierarki dan grup yang mudah berubah.
• Bagaimana penataan ulang akses yang besar diuji, dijadwalkan, dihitung ulang sekali, dan diverifikasi pada volume produksi.
• Apakah kebutuhan keamanan yang berbeda membenarkan pemisahan data alih-alih memperumit akses ke satu rekaman.
• Bagaimana akses mitra, karyawan, aplikasi, dan agen tetap terikat pada hubungan bisnis, bukan jalan pintas identitas.

Mudah menggambar desain yang aman untuk 1.000 rekaman, atau desain yang cepat di mana semua orang melihat segalanya. Tugas arsitek adalah sistem tempat keduanya bertahan: orang yang tepat melihat data yang tepat, dan semuanya tetap berjalan ketika kita menambahkan nol. Dalam skala besar, berbagi adalah bagian dari arsitektur data.

Jelajahi

• Object Reference for the Salesforce Platform, WorkOrderShare (terbuka di tab baru) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (terbuka di tab baru) (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (terbuka di tab baru), Group Membership Locking (terbuka di tab baru) and Deferred Sharing Maintenance (terbuka di tab baru), checked 2026-11-01. ⟲
• Untuk pendalaman: kursus Sharing and Visibility Architect, Berbagi dalam Skala Besar (coming soon).
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲
• Salesforce, Record-Level Access: Under the Hood (terbuka di tab baru) (Winter ‘27, archived copy (terbuka di tab baru)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (terbuka di tab baru) and Sharing a Record Using Apex (terbuka di tab baru), checked 2026-11-01. ⟲