Quando il volume incontra il modello di condivisione

🌐 Disponibile anche in 19 lingue

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

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese Questa sezione è cambiata in inglese e non è ancora stata tradotta di nuovo. (35)

Modulo 3 di 4 del capitolo Progettare per la scala, capitolo 7 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Punti caldi: squilibrio di titolarità, di padre e di ricerca · Successivo: Se non archivi oggi…

La domanda a cui risponde questo modulo: Come resta veloce ad alto volume un modello che rispetta la condivisione?

Il modulo precedente ha trovato i punti caldi. Ora aggiungi la sicurezza, dove un’architettura dei dati dall’aria ragionevole diventa costosa. Nove milioni di ordini di lavoro sono un problema di volume. Nove milioni di ordini di lavoro, ciascuno visibile esattamente agli utenti interni giusti e esattamente al partner retail giusto, sono un problema di condivisione ad alto volume. Un record non viene solo memorizzato; Salesforce deve anche rispondere a chi può vederlo? Su larga scala, quella risposta fa parte dell’architettura dei dati.

Anche la condivisione è un dato

Quando gli architetti contano il volume, contano i record di business. Ma Salesforce mantiene anche ciò che sostiene l’accesso: titolari, ruoli, gruppi, regole di condivisione, condivisioni esplicite, appartenenze. Su piccola scala puoi dimenticare che quel lavoro esiste. Su grande scala no. Per questo non dico mai “la condivisione la sistemerà il team di sicurezza più avanti”. La relazione che scelgo, il titolare, il padre, il modello degli utenti esterni: ognuno incide sulla condivisione. L’architetto dei dati e l’architetto della condivisione possono essere persone diverse, ma le loro architetture sono collegate.

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 (si apre in una nuova scheda); Sharing a Record Using Apex (si apre in una nuova scheda)). 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 (si apre in una nuova scheda), Winter ‘27, archived copy (si apre in una nuova scheda)). 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 (si apre in una nuova scheda)). 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. ⟲

Clicca per ingrandire

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

Clicca per ingrandire

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

Clicca per ingrandire

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

Parti dal requisito di accesso

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

La gerarchia dei ruoli non è un organigramma

I team progettano la gerarchia dei ruoli come specchio dell’organigramma. Poi l’azienda si riorganizza, qualcuno sposta un ruolo, e Salesforce deve calcolare le conseguenze sugli accessi. Su piccola scala nessuno se ne accorge. Con milioni di record, una riorganizzazione è una grande operazione sui dati. Per questo l’indicazione per i titolari ad alto volume è nessun ruolo, o un ruolo separato e stabile in cima alla gerarchia (Ownership Data Skew (si apre in una nuova scheda)). Il principio si generalizza: su larga scala, la stabilità è una caratteristica di progetto. Più record dipendono da una struttura di condivisione, più attenzione serve per cambiarla.

Con i gruppi è lo stesso. I gruppi pubblici alimentano le regole di condivisione; gli utenti appartengono ai gruppi; i gruppi contengono gruppi. Strumenti utili, ma se popolazioni enormi di utenti e record dipendono da appartenenze ai gruppi che cambiano di continuo, devi capire il ricalcolo. Per questo i titolari ad alto volume restano fuori dai gruppi pubblici usati come origine delle regole di condivisione (stessa fonte). La lezione non è “i gruppi pubblici sono cattivi”. È: non collegare la tua più grande concentrazione di record alle tue strutture di accesso più volatili senza pensarci bene.

Il ricalcolo della condivisione è lavoro vero

Steve Trucking cambia il suo modello operativo: centinaia di utenti si spostano, la titolarità cambia, ruoli e gruppi cambiano, una grande regola di condivisione cambia. Sembra configurazione. Ma la piattaforma potrebbe dover ricalcolare l’accesso su una grande popolazione di record, quindi lo tratto come un’operazione sui dati. Quanti utenti, record, cambi di titolarità e di appartenenza? Quanto ricalcolo? Possiamo testarlo al volume reale? Quando deve girare, e cosa vedono gli utenti nel frattempo? Un grande riallineamento della sicurezza merita la stessa disciplina di una grande migrazione dei dati.

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 (si apre in una nuova scheda)). 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 (si apre in una nuova scheda), 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. ⟲

Clicca per ingrandire

At scale, access realignment is a data operation. ⟲

“Rimandato” non vuol dire alla leggera. Se una modifica è abbastanza grande da rimandare la condivisione, voglio un piano: testato a un volume realistico, una finestra di manutenzione su cui il business è d’accordo, una verifica, un piano di riserva se non finisce, e la comprensione di cosa vivono gli utenti nel frattempo. L’indicazione di Salesforce è modellarlo prima in una sandbox Full (full copy sandbox; stessa fonte), perché un modello di sicurezza che funziona benissimo con 5.000 record di test non dimostra niente su 50 milioni. Testa il Numero di Zeri per cui stai davvero progettando.

Il blocco granulare aiuta, ma non è una cura

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 (si apre in una nuova scheda)); 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’isolamento dei partner su larga scala

Al Checkpoint 1, ogni ordine di lavoro porta il suo partner retail, in modo stabile, perché l’isolamento dei partner è un requisito. I numeri della scala lo rendono più importante, non meno: se Redrock vale il 40% del business, sono circa 3,6 milioni di ordini di lavoro Redrock in cinque anni. La relazione è giusta; Redrock è davvero un solo partner. Quindi il progetto degli accessi deve seguire la vera relazione di business (gli utenti partner vedono gli ordini di lavoro del proprio partner, i responsabili di CD solo quelli del proprio CD) invece di distorcere il modello. La struttura con un account figlio per CD del modulo precedente aiuta qui due volte: distribuisce i figli, e dà all’accesso a livello di CD qualcosa di reale a cui agganciarsi.

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

L’accesso interno è diverso ancora

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

A volte la sicurezza deve cambiare il modello. Quando due tipi di informazione hanno titolari, cicli di vita, pubblici o esigenze di condivisione completamente diversi, puoi accumulare controlli a livello di campo su un solo record, oppure separare i dati in un oggetto proprio con un proprio confine. Non separo solo per evitare di configurare la sicurezza a livello di campo, ma la sicurezza è un motivo legittimo per cambiare il modello fisico.

Anche la condivisione ha il suo Numero di Zeri

Due progetti con 10 milioni di record ciascuno: uno con titolarità semplice, gerarchia stabile, poche regole di condivisione e poco movimento nelle appartenenze; l’altro con titolarità molto distribuita, ruoli che cambiano spesso, grandi gruppi annidati, tante regole di condivisione e riorganizzazioni continue. Stesso numero di record, problema di scala completamente diverso. Quindi per ogni oggetto ad alto volume voglio anche i numeri del modello di accesso: quanti titolari e quanto concentrati, l’accesso predefinito, quali relazioni di gerarchia, regole e gruppi contano, quanti utenti esterni, e cosa succede quando qualcuno cambia ruolo, si aggiunge un partner o si riorganizza una regione. Poi una domanda: qual è il ricalcolo più grande che questo progetto potrebbe scatenare? È lo scenario che voglio vedere testato.

Clicca per ingrandire

Count the access model, not just the records. ⟲

Non sacrificare la sicurezza all’ottimizzazione

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

Oltre l’esame: cosa cambia l’IA. Gli agenti recuperano e aggregano più in fretta di qualsiasi persona, e questo rende più pericoloso un modello di accesso troppo ampio. Non affidarti a un prompt che dice “non mostrare i dati di Brightwave a Redrock”. Il confine appartiene all’architettura: è l’autorizzazione che deve limitare ciò che un agente può raggiungere, non le istruzioni su ciò che sceglie di rivelare. Fai crescere il modello di autorizzazione insieme al modello dei dati.

Cosa decide qui un architetto

• Quali relazioni, titolari, ruoli, gruppi e regole di condivisione guidano l’accesso per ogni oggetto ad alto volume.
• Se i titolari ad alto volume e gli altri punti caldi sono isolati dalle strutture volatili di gerarchia e di gruppo.
• Come i grandi riallineamenti degli accessi vengono testati, pianificati, ricalcolati una volta e verificati al volume di produzione.
• Se esigenze di sicurezza diverse giustificano la separazione dei dati invece di complicare l’accesso a un solo record.
• Come l’accesso di partner, dipendenti, applicazioni e agenti resta legato alle relazioni di business, non a scorciatoie sull’identità.

È facile disegnare un progetto sicuro per 1.000 record, e uno veloce in cui tutti vedono tutto. Il lavoro dell’architetto è il sistema in cui sopravvivono entrambi: le persone giuste vedono i dati giusti, e funziona ancora quando aggiungiamo gli zeri. Su larga scala, la condivisione fa parte dell’architettura dei dati.

Per approfondire

• Object Reference for the Salesforce Platform, WorkOrderShare (si apre in una nuova scheda) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (si apre in una nuova scheda) (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 (si apre in una nuova scheda), Group Membership Locking (si apre in una nuova scheda) and Deferred Sharing Maintenance (si apre in una nuova scheda), checked 2026-11-01. ⟲
• Per approfondire: il corso Sharing and Visibility Architect, La condivisione su larga scala (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 (si apre in una nuova scheda) (Winter ‘27, archived copy (si apre in una nuova scheda)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (si apre in una nuova scheda) and Sharing a Record Using Apex (si apre in una nuova scheda), checked 2026-11-01. ⟲