Hacim Paylaşım Modeliyle Buluştuğunda

🌐 19 dilde daha mevcut

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

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku Bu bölüm İngilizcede değişti ve henüz yeniden çevrilmedi. (35)

Data Architect kursunun 7. bölümü olan Ölçek İçin Tasarlamak bölümündeki 4 modülden 3.‘sü. Her modül kendi başına okunabilir. Önceki: Sıcak Noktalar: Sahiplik, Üst Kayıt ve Arama Çarpıklığı · Sonraki: Bugün Arşivlemiyorsanız…

Bu modülün yanıtladığı soru: Paylaşıma saygı duyan bir model hacimde nasıl hızlı kalır?

Son modül sıcak noktaları buldu. Şimdi güvenliği ekleyin; makul görünen bir veri mimarisi burada pahalılaşır. Dokuz milyon iş emri bir hacim sorunudur. Her biri tam olarak doğru iç kullanıcılara ve tam olarak doğru Perakende Ortağı’na görünen dokuz milyon iş emri ise bir hacimde paylaşım sorunudur. Bir kayıt yalnızca depolanmaz; Salesforce ayrıca onu kim görebilir? sorusunu yanıtlamak zorundadır. Ölçekte bu yanıt veri mimarisinin bir parçasıdır.

Paylaşım da Veridir

Mimarlar hacmi sayarken iş kayıtlarını sayar. Ama Salesforce erişimi destekleyen şeyleri de tutar: sahipler, roller, gruplar, paylaşım kuralları, açık paylaşımlar, üyelikler. Küçük ölçekte bu işin var olduğunu unutabilirsiniz. Büyük ölçekte unutamazsınız. Bu yüzden asla “paylaşımı güvenlik ekibi sonra halleder” demem. Seçtiğim ilişki, sahip, üst kayıt, dış kullanıcı modeli: her biri paylaşımı etkiler. Veri mimarı ile paylaşım mimarı farklı kişiler olabilir, ama mimarileri birbirine bağlıdır.

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 (yeni sekmede açılır); Sharing a Record Using Apex (yeni sekmede açılır)). 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 (yeni sekmede açılır), Winter ‘27, archived copy (yeni sekmede açılır)). 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 (yeni sekmede açılır)). 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. ⟲

Büyütmek için tıklayın

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

Büyütmek için tıklayın

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

Büyütmek için tıklayın

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. ⟲

Erişim Gereksinimiyle Başlayın

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. ⟲

Rol Hiyerarşisi Bir Organizasyon Şeması Değildir

Ekipler rol hiyerarşisini organizasyon şemasını yansıtacak şekilde tasarlar. Sonra şirket yeniden yapılanır, biri bir rolü taşır ve Salesforce erişim sonuçlarını hesaplamak zorunda kalır. Küçük ölçekte kimse fark etmez. Milyonlarca kayıtta yeniden yapılanma büyük bir veri operasyonudur. Bu yüzden yüksek hacimli sahipler için rehberlik rol yok ya da hiyerarşinin en üstünde ayrı, sabit bir roldür (Ownership Data Skew (yeni sekmede açılır)). İlke genelleşir: ölçekte istikrar bir tasarım özelliğidir. Bir paylaşım yapısına ne kadar çok kayıt bağlıysa, onu o kadar dikkatli değiştirirsiniz.

Gruplar da öyle. Herkese açık gruplar paylaşım kurallarını besler; kullanıcılar gruplara aittir; gruplar grupları içerir. Yararlı araçlar, ama devasa kullanıcı ve kayıt kitleleri sürekli değişen grup üyeliğine bağlıysa yeniden hesaplamayı anlamanız gerekir. Bu yüzden yüksek hacimli sahipler paylaşım kuralı kaynağı olarak kullanılan herkese açık grupların dışında kalır (aynı kaynak). Ders “herkese açık gruplar kötüdür” değil. Ders şu: en büyük kayıt yoğunlaşmanızı, iyice düşünmeden en değişken erişim yapılarınıza bağlamayın.

Paylaşımın Yeniden Hesaplanması Gerçek Bir İştir

Steve Trucking işletme modelini değiştiriyor: yüzlerce kullanıcı yer değiştiriyor, sahiplik değişiyor, roller ve gruplar değişiyor, büyük bir paylaşım kuralı değişiyor. Kulağa yapılandırma gibi geliyor. Ama platformun büyük bir kayıt kitlesinde erişimi yeniden hesaplaması gerekebilir, bu yüzden bunu bir veri operasyonu olarak ele alırım. Kaç kullanıcı, kayıt, sahiplik ve üyelik değişikliği? Ne kadar yeniden hesaplama? Gerçek hacimde test edebilir miyiz? Ne zaman çalışmalı ve bu sırada kullanıcılar ne görüyor? Büyük bir güvenlik yeniden düzenlemesi, büyük bir veri taşımasıyla aynı disiplini hak eder.

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 (yeni sekmede açılır)). 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 (yeni sekmede açılır), 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. ⟲

Büyütmek için tıklayın

At scale, access realignment is a data operation. ⟲

“Ertelenmiş” gelişigüzel demek değildir. Bir değişiklik paylaşımı ertelemeye yetecek kadar büyükse bir plan isterim: gerçekçi hacimde test edilmiş, işin kabul ettiği bir bakım penceresi, doğrulama, bitmezse bir geri dönüş planı ve bu sırada kullanıcıların ne yaşadığına dair bir anlayış. Salesforce’un rehberliği bunu önce bir tam kopya sandbox’ta (full copy sandbox; aynı kaynak) modellemektir, çünkü 5.000 test kaydıyla harika çalışan bir güvenlik modeli 50 milyon hakkında hiçbir şey kanıtlamaz. Gerçekten tasarladığınız Sıfır Sayısı’nı test edin.

Ayrıntılı Kilitleme Yardımcı Olur, Ama Çare Değildir

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 (yeni sekmede açılır)); 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: Ölçekte Ortak Yalıtımı

1. Kontrol Noktası’nda her iş emri Perakende Ortağı’nı kalıcı olarak taşır, çünkü ortak yalıtımı bir gereksinimdir. Ölçek rakamları bunu daha az değil, daha önemli kılar: Redrock işin %40’ıysa, beş yılda yaklaşık 3,6 milyon Redrock iş emri demektir. İlişki doğru; Redrock gerçekten tek bir ortak. Bu yüzden erişim tasarımı modeli çarpıtmak yerine gerçek iş ilişkisini izlemelidir (ortak kullanıcılar kendi ortaklarının iş emirlerini, DC yöneticileri yalnızca kendi DC’lerininkileri görür). Son modüldeki DC başına alt hesap yapısı burada iki kez işe yarar: alt kayıtları dağıtır ve DC düzeyinde erişime tutunacak gerçek bir şey verir.

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. ⟲

İç Erişim Yine Farklıdır

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. ⟲

Bazen güvenlik modeli değiştirmelidir. İki tür bilginin sahipleri, yaşam döngüleri, hedef kitleleri veya paylaşım ihtiyaçları tamamen farklıysa, ya tek bir kayda alan düzeyinde kontroller yığarsınız ya da veriyi kendi sınırı olan ayrı bir nesneye bölersiniz. Yalnızca alan düzeyinde güvenliği yapılandırmaktan kaçınmak için bölmem, ama güvenlik fiziksel modeli değiştirmek için meşru bir nedendir.

Paylaşımın da Kendi Sıfır Sayısı Vardır

Her birinde 10 milyon kayıt olan iki tasarım: biri basit sahiplik, sabit bir hiyerarşi, az paylaşım kuralı ve az üyelik değişikliğiyle; diğeri çok dağınık sahiplik, sık değişen roller, büyük iç içe gruplar, çok sayıda paylaşım kuralı ve sürekli yeniden yapılanmayla. Aynı kayıt sayısı, tamamen farklı bir ölçek sorunu. Bu yüzden her yüksek hacimli nesne için erişim modelinin rakamlarını da isterim: kaç sahip ve ne kadar yoğunlaşmış, varsayılan erişim, hangi hiyerarşi ilişkilerinin, kuralların ve grupların önemli olduğu, kaç dış kullanıcı olduğu ve biri rol değiştirdiğinde, bir ortak eklendiğinde ya da bir bölge yeniden yapılandığında ne olduğu. Sonra tek bir soru: bu tasarımın tetikleyebileceği en büyük yeniden hesaplama nedir? Test edilmesini istediğim senaryo budur.

Büyütmek için tıklayın

Count the access model, not just the records. ⟲

Güvenliği Optimizasyona Kurban Etmeyin

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. ⟲

Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanlar herkesten hızlı getirir ve birleştirir; bu da aşırı geniş bir erişim modelini daha tehlikeli kılar. “Brightwave’in verilerini Redrock’a gösterme” diyen bir istem metnine güvenmeyin. Sınır mimaride yer alır: ajanın neye erişebileceğini yetkilendirme sınırlamalıdır, neyi açığa çıkarmayı seçtiğini talimatlar değil. Yetkilendirme modelini veri modeliyle birlikte ölçeklendirin.

Mimarın Burada Karar Verdikleri

• Her yüksek hacimli nesne için hangi ilişkilerin, sahiplerin, rollerin, grupların ve paylaşım kurallarının erişimi yönlendirdiği.
• Yüksek hacimli sahiplerin ve diğer sıcak noktaların değişken hiyerarşi ve grup yapılarından yalıtılıp yalıtılmadığı.
• Büyük erişim yeniden düzenlemelerinin üretim hacminde nasıl test edildiği, planlandığı, bir kez yeniden hesaplandığı ve doğrulandığı.
• Farklı güvenlik ihtiyaçlarının, tek bir kayda erişimi karmaşıklaştırmak yerine veriyi bölmeyi haklı çıkarıp çıkarmadığı.
• Ortak, çalışan, uygulama ve ajan erişiminin kimlik kısayollarına değil, iş ilişkilerine nasıl bağlı kaldığı.

1.000 kayıt için güvenli bir tasarım çizmek kolaydır, herkesin her şeyi gördüğü hızlı bir tasarım çizmek de. Mimarın işi, ikisinin de ayakta kaldığı sistemdir: doğru kişiler doğru veriyi görür ve sıfırları eklediğimizde de çalışmaya devam eder. Ölçekte paylaşım, veri mimarisinin bir parçasıdır.

Daha Fazlası

• Object Reference for the Salesforce Platform, WorkOrderShare (yeni sekmede açılır) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (yeni sekmede açılır) (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 (yeni sekmede açılır), Group Membership Locking (yeni sekmede açılır) and Deferred Sharing Maintenance (yeni sekmede açılır), checked 2026-11-01. ⟲
• Derinlik için: Sharing and Visibility Architect kursunun Ölçekte Paylaşım (coming soon) bölümü.
• 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 (yeni sekmede açılır) (Winter ‘27, archived copy (yeni sekmede açılır)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (yeni sekmede açılır) and Sharing a Record Using Apex (yeni sekmede açılır), checked 2026-11-01. ⟲