Quand le volume rencontre le modèle de partage

🌐 Aussi en 19 langues

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

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais Cette section a changé en anglais et n’a pas encore été retraduite. (35)

Module 3 sur 4 du chapitre Concevoir pour le volume, chapitre 7 du cours Data Architect. Chaque module est autonome. Précédent : Points chauds : déséquilibre de propriété, de parent et de référence · Suivant : Si vous n’archivez pas aujourd’hui…

La question à laquelle répond ce module : comment un modèle qui respecte le partage reste-t-il rapide à fort volume ?

Le module précédent a trouvé les points chauds. Ajoutons maintenant la sécurité, là où une architecture de données d’apparence raisonnable devient coûteuse. Neuf millions d’ordres d’exécution, c’est un problème de volume. Neuf millions d’ordres d’exécution, chacun visible exactement par les bons utilisateurs internes et exactement par le bon partenaire distributeur, c’est un problème de partage à grande échelle. Un enregistrement n’est pas seulement stocké ; Salesforce doit aussi répondre à la question qui peut le voir ? À grande échelle, cette réponse fait partie de l’architecture de données.

Le partage, c’est aussi des données

Quand les architectes comptent le volume, ils comptent les enregistrements métier. Mais Salesforce maintient aussi ce qui soutient l’accès : propriétaires, rôles, groupes, règles de partage, partages explicites, appartenances. À petite échelle, on peut oublier que ce travail existe. À grande échelle, non. C’est pour cela que je ne dis jamais « l’équipe sécurité réglera le partage plus tard ». La relation que je choisis, le propriétaire, le parent, le modèle d’utilisateurs externes : chacun affecte le partage. L’architecte de données et l’architecte du partage peuvent être des personnes différentes, mais leurs architectures sont liées.

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 (s'ouvre dans un nouvel onglet); Sharing a Record Using Apex (s'ouvre dans un nouvel onglet)). 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 (s'ouvre dans un nouvel onglet), Winter ‘27, archived copy (s'ouvre dans un nouvel onglet)). 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 (s'ouvre dans un nouvel onglet)). 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. ⟲

Cliquer pour agrandir

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

Cliquer pour agrandir

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

Cliquer pour agrandir

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

Commencez par le besoin d’accès

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 hiérarchie des rôles n’est pas un organigramme

Les équipes conçoivent la hiérarchie des rôles comme un reflet de l’organigramme. Puis l’entreprise se réorganise, quelqu’un déplace un rôle, et Salesforce doit calculer les conséquences sur les accès. À petite échelle, personne ne remarque rien. À des millions d’enregistrements, une réorganisation est une grosse opération sur les données. C’est pour cela que la recommandation pour les propriétaires à fort volume est de ne leur donner aucun rôle, ou un rôle distinct et stable au sommet de la hiérarchie (Ownership Data Skew (s'ouvre dans un nouvel onglet)). Le principe se généralise : à grande échelle, la stabilité est une caractéristique de conception. Plus il y a d’enregistrements suspendus à une structure de partage, plus il faut la modifier avec précaution.

Les groupes, c’est pareil. Les groupes publics alimentent les règles de partage ; les utilisateurs appartiennent à des groupes ; des groupes contiennent des groupes. Des outils utiles, mais si d’énormes populations d’utilisateurs et d’enregistrements dépendent d’appartenances à des groupes qui changent tout le temps, vous devez comprendre le recalcul. C’est pour cela que les propriétaires à fort volume restent hors des groupes publics utilisés comme sources des règles de partage (même source). La leçon n’est pas « les groupes publics, c’est mal ». C’est : ne reliez pas votre plus grosse concentration d’enregistrements à vos structures d’accès les plus volatiles sans y avoir bien réfléchi.

Le recalcul du partage est un vrai travail

Steve Trucking change son modèle opérationnel : des centaines d’utilisateurs bougent, la propriété change, les rôles et les groupes changent, une grosse règle de partage change. On dirait de la configuration. Mais la plateforme peut devoir recalculer les accès sur une grande population d’enregistrements, alors je le traite comme une opération sur les données. Combien d’utilisateurs, d’enregistrements, de changements de propriété et d’appartenance ? Combien de recalcul ? Pouvons-nous le tester au vrai volume ? Quand cela doit-il tourner, et que voient les utilisateurs pendant ce temps ? Un grand réalignement de la sécurité mérite la même discipline qu’une grande migration de données.

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 (s'ouvre dans un nouvel onglet)). 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 (s'ouvre dans un nouvel onglet), 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. ⟲

Cliquer pour agrandir

At scale, access realignment is a data operation. ⟲

« Différé » ne veut pas dire désinvolte. Si un changement est assez gros pour différer le partage, je veux un plan : testé à un volume réaliste, une fenêtre de maintenance acceptée par le métier, une vérification, une solution de repli si cela ne se termine pas, et une compréhension de ce que vivent les utilisateurs pendant ce temps. La recommandation de Salesforce est de le modéliser d’abord dans un sandbox complet (full copy sandbox ; même source), parce qu’un modèle de sécurité qui fonctionne à merveille avec 5 000 enregistrements de test ne prouve rien pour 50 millions. Testez le Nombre de zéros pour lequel vous concevez réellement.

Le verrouillage granulaire aide, mais ce n’est pas un remède

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 (s'ouvre dans un nouvel onglet)); 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’isolement des partenaires à grande échelle

Au point de contrôle 1, chaque ordre d’exécution porte son partenaire distributeur, durablement, parce que l’isolement des partenaires est une exigence. Les chiffres de volume rendent cela plus important, pas moins : si Redrock représente 40 % de l’activité, cela fait environ 3,6 millions d’ordres d’exécution Redrock sur cinq ans. La relation est juste ; Redrock est vraiment un seul partenaire. La conception des accès doit donc suivre la vraie relation métier (les utilisateurs partenaires voient les ordres d’exécution de leur partenaire, les responsables de centre de distribution seulement ceux de leur centre) plutôt que déformer le modèle. La structure d’un compte enfant par centre de distribution, vue au module précédent, aide ici deux fois : elle répartit les enfants, et elle donne à l’accès par centre de distribution quelque chose de réel auquel se rattacher.

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’accès interne est encore différent

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

Parfois, la sécurité doit changer le modèle. Quand deux types d’information ont des propriétaires, des cycles de vie, des publics ou des besoins de partage complètement différents, vous pouvez empiler des contrôles au niveau des champs sur un seul enregistrement, ou séparer les données dans leur propre objet avec sa propre frontière. Je ne sépare pas juste pour éviter de configurer la sécurité au niveau des champs, mais la sécurité est une raison légitime de changer le modèle physique.

Le partage a son propre Nombre de zéros

Deux conceptions avec chacune 10 millions d’enregistrements : l’une avec une propriété simple, une hiérarchie stable, peu de règles de partage et peu de mouvements dans les appartenances ; l’autre avec une propriété très distribuée, des rôles qui changent souvent, de gros groupes imbriqués, beaucoup de règles de partage et des réorganisations permanentes. Même nombre d’enregistrements, problème d’échelle complètement différent. Donc, pour chaque objet à fort volume, je veux aussi les chiffres du modèle d’accès : combien de propriétaires et à quel point concentrés, l’accès par défaut, quelles relations de hiérarchie, règles et groupes comptent, combien d’utilisateurs externes, et ce qui se passe quand quelqu’un change de rôle, qu’un partenaire est ajouté ou qu’une région est réorganisée. Puis une question : quel est le plus gros recalcul que cette conception pourrait provoquer ? C’est le scénario que je veux voir testé.

Cliquer pour agrandir

Count the access model, not just the records. ⟲

N’optimisez pas au détriment de la sécurité

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

Au-delà de l’examen : ce que l’IA change. Les agents récupèrent et agrègent plus vite que n’importe quelle personne, ce qui rend un modèle d’accès trop large plus dangereux. Ne comptez pas sur un prompt qui dit « ne montre pas les données de Brightwave à Redrock ». La frontière appartient à l’architecture : c’est l’autorisation qui doit limiter ce qu’un agent peut atteindre, pas des instructions sur ce qu’il choisit de révéler. Faites évoluer le modèle d’autorisation avec le modèle de données.

Ce que l’architecte décide ici

• Quelles relations, quels propriétaires, rôles, groupes et règles de partage pilotent l’accès pour chaque objet à fort volume.
• Si les propriétaires à fort volume et les autres points chauds sont isolés des structures de hiérarchie et de groupes volatiles.
• Comment les grands réalignements d’accès sont testés, planifiés, recalculés une seule fois et vérifiés au volume de production.
• Si des besoins de sécurité différents justifient de séparer les données plutôt que de compliquer l’accès à un seul enregistrement.
• Comment l’accès des partenaires, des employés, des applications et des agents reste rattaché aux relations métier, et non à des raccourcis d’identité.

Il est facile de dessiner une conception sûre pour 1 000 enregistrements, et une conception rapide où tout le monde voit tout. Le travail de l’architecte, c’est le système où les deux survivent : les bonnes personnes voient les bonnes données, et cela fonctionne encore quand on ajoute les zéros. À grande échelle, le partage fait partie de l’architecture de données.

Pour aller plus loin

• Object Reference for the Salesforce Platform, WorkOrderShare (s'ouvre dans un nouvel onglet) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (s'ouvre dans un nouvel onglet) (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 (s'ouvre dans un nouvel onglet), Group Membership Locking (s'ouvre dans un nouvel onglet) and Deferred Sharing Maintenance (s'ouvre dans un nouvel onglet), checked 2026-11-01. ⟲
• Pour approfondir : le cours Sharing and Visibility Architect, Le partage à grande échelle (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 (s'ouvre dans un nouvel onglet) (Winter ‘27, archived copy (s'ouvre dans un nouvel onglet)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (s'ouvre dans un nouvel onglet) and Sharing a Record Using Apex (s'ouvre dans un nouvel onglet), checked 2026-11-01. ⟲