O volume encontra o modelo de compartilhamento

🌐 Também em 19 idiomas

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

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês Esta seção mudou em inglês e ainda não foi traduzida de novo. (35)

Módulo 3 de 4 do capítulo Projetando para escala, capítulo 7 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Pontos quentes: desequilíbrio de propriedade, de pai e de pesquisa · Próximo: Se você não arquiva hoje…

A pergunta que este módulo responde: Como um modelo que respeita o compartilhamento continua rápido com volume?

O módulo anterior encontrou os pontos quentes. Agora acrescente a segurança, que é onde uma arquitetura de dados de aparência razoável fica cara. Nove milhões de ordens de serviço é um problema de volume. Nove milhões de ordens de serviço, cada uma visível exatamente para os usuários internos certos e exatamente para o parceiro varejista certo, é um problema de compartilhamento com volume. Um registro não é só armazenado; o Salesforce também precisa responder quem pode vê-lo? Em escala, essa resposta faz parte da arquitetura de dados.

O compartilhamento também é dado

Quando os arquitetos contam o volume, contam registros de negócio. Mas o Salesforce também mantém o que sustenta o acesso: proprietários, papéis, grupos, regras de compartilhamento, compartilhamentos explícitos, associações. Em pequena escala, dá para esquecer que esse trabalho existe. Em grande escala, não dá. É por isso que eu nunca digo “a equipe de segurança resolve o compartilhamento depois”. O relacionamento que eu escolho, o proprietário, o pai, o modelo de usuários externos: cada um afeta o compartilhamento. O arquiteto de dados e o arquiteto de compartilhamento podem ser pessoas diferentes, mas as arquiteturas deles estão conectadas.

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 (abre em uma nova aba); Sharing a Record Using Apex (abre em uma nova aba)). 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 (abre em uma nova aba), Winter ‘27, archived copy (abre em uma nova aba)). 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 (abre em uma nova aba)). 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. ⟲

Clique para ampliar

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

Clique para ampliar

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

Clique para ampliar

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

Comece pelo requisito de acesso

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

A hierarquia de papéis não é um organograma

As equipes projetam a hierarquia de papéis como espelho do organograma. Então a empresa se reorganiza, alguém move um papel, e o Salesforce tem de calcular as consequências para o acesso. Em pequena escala, ninguém percebe. Com milhões de registros, reorganizar é uma grande operação de dados. Por isso a orientação para proprietários de alto volume é dar a eles nenhum papel, ou um papel separado e estável no topo da hierarquia (Ownership Data Skew (abre em uma nova aba)). O princípio se generaliza: em escala, a estabilidade é uma característica do design. Quanto mais registros dependem de uma estrutura de compartilhamento, mais cuidado você tem ao mudá-la.

Os grupos são iguais. Os grupos públicos alimentam as regras de compartilhamento; os usuários pertencem a grupos; grupos contêm grupos. São ferramentas úteis, mas se populações enormes de usuários e registros dependem de associações a grupos que mudam o tempo todo, você precisa entender o recálculo. Por isso os proprietários de alto volume ficam fora dos grupos públicos usados como origem de regras de compartilhamento (mesma fonte). A lição não é “grupos públicos são ruins”. É: não ligue a sua maior concentração de registros às suas estruturas de acesso mais voláteis sem pensar bem.

O recálculo do compartilhamento é trabalho de verdade

A Steve Trucking muda o seu modelo operacional: centenas de usuários mudam de lugar, a propriedade muda, papéis e grupos mudam, uma grande regra de compartilhamento muda. Parece configuração. Mas a plataforma pode ter de recalcular o acesso numa grande população de registros, então eu trato isso como uma operação de dados. Quantos usuários, registros, mudanças de propriedade e de associação? Quanto recálculo? Podemos testar com o volume real? Quando deve rodar, e o que os usuários veem enquanto isso? Um grande realinhamento de segurança merece a mesma disciplina que uma grande migração de dados.

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 (abre em uma nova aba)). 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 (abre em uma nova aba), 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. ⟲

Clique para ampliar

At scale, access realignment is a data operation. ⟲

“Adiado” não quer dizer descuidado. Se uma mudança é grande o bastante para adiar o compartilhamento, quero um plano: testado com volume realista, uma janela de manutenção com que o negócio concorde, verificação, uma alternativa se não terminar, e o entendimento do que os usuários vivem enquanto isso. A orientação do Salesforce é modelar primeiro num sandbox de cópia completa (mesma fonte), porque um modelo de segurança que funciona lindamente com 5.000 registros de teste não prova nada sobre 50 milhões. Teste o Número de Zeros para o qual você está realmente projetando.

O bloqueio granular ajuda, mas não é a 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 (abre em uma nova aba)); 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: isolamento de parceiros em escala

No Checkpoint 1, toda ordem de serviço leva o seu parceiro varejista, de forma duradoura, porque o isolamento de parceiros é um requisito. Os números de escala tornam isso mais importante, não menos: se a Redrock é 40% do negócio, são cerca de 3,6 milhões de ordens de serviço da Redrock em cinco anos. O relacionamento está certo; a Redrock realmente é um parceiro só. Então o design de acesso precisa seguir o relacionamento de negócio real (os usuários do parceiro veem as ordens de serviço do seu parceiro, os gerentes de CD só as do seu CD) em vez de distorcer o modelo. A estrutura de uma conta filha por CD, do módulo anterior, ajuda aqui duas vezes: espalha os filhos e dá ao acesso por CD algo real em que se apoiar.

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

O acesso interno é outra história

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

Às vezes a segurança deve mudar o modelo. Quando dois tipos de informação têm proprietários, ciclos de vida, públicos ou necessidades de compartilhamento completamente diferentes, você pode empilhar controles de nível de campo num registro, ou separar os dados num objeto próprio com o seu próprio limite. Não separo só para evitar configurar a segurança em nível de campo, mas a segurança é um motivo legítimo para mudar o modelo físico.

O compartilhamento tem o seu próprio Número de Zeros

Dois designs com 10 milhões de registros cada: um com propriedade simples, hierarquia estável, poucas regras de compartilhamento e pouca rotatividade de associações; o outro com propriedade muito distribuída, papéis que mudam com frequência, grandes grupos aninhados, muitas regras de compartilhamento e reorganização constante. A mesma contagem de registros, um problema de escala completamente diferente. Então, para cada objeto de alto volume, também quero os números do modelo de acesso: quantos proprietários e quão concentrados, o acesso padrão, quais relações de hierarquia, regras e grupos importam, quantos usuários externos, e o que acontece quando alguém muda de papel, um parceiro é adicionado ou uma região é reorganizada. Depois, uma pergunta: qual é o maior recálculo que este design pode causar? É esse o cenário que quero testado.

Clique para ampliar

Count the access model, not just the records. ⟲

Não sacrifique a segurança em nome da otimização

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

Além do exame: o que a IA muda. Os agentes recuperam e agregam dados mais rápido que qualquer pessoa, o que torna um modelo de acesso amplo demais mais perigoso. Não confie num prompt que diga “não mostre os dados da Brightwave para a Redrock”. O limite pertence à arquitetura: a autorização deve limitar o que um agente pode alcançar, não instruções o que ele escolhe revelar. Escale o modelo de autorização junto com o modelo de dados.

O que um arquiteto decide aqui

• Quais relacionamentos, proprietários, papéis, grupos e regras de compartilhamento determinam o acesso a cada objeto de alto volume.
• Se os proprietários de alto volume e outros pontos quentes estão isolados das estruturas voláteis de hierarquia e de grupos.
• Como os grandes realinhamentos de acesso são testados, programados, recalculados uma vez e verificados com o volume de produção.
• Se necessidades de segurança diferentes justificam separar os dados, em vez de complicar o acesso a um registro.
• Como o acesso de parceiros, funcionários, aplicações e agentes continua ligado a relacionamentos de negócio, não a atalhos de identidade.

É fácil desenhar um design seguro para 1.000 registros, e um rápido em que todo mundo vê tudo. O trabalho do arquiteto é o sistema em que os dois sobrevivem: as pessoas certas veem os dados certos, e ainda funciona quando acrescentamos os zeros. Em escala, o compartilhamento faz parte da arquitetura de dados.

Para saber mais

• Object Reference for the Salesforce Platform, WorkOrderShare (abre em uma nova aba) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (abre em uma nova aba) (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 (abre em uma nova aba), Group Membership Locking (abre em uma nova aba) and Deferred Sharing Maintenance (abre em uma nova aba), checked 2026-11-01. ⟲
• Para se aprofundar: o curso Sharing and Visibility Architect, Compartilhamento em escala (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 (abre em uma nova aba) (Winter ‘27, archived copy (abre em uma nova aba)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (abre em uma nova aba) and Sharing a Record Using Apex (abre em uma nova aba), checked 2026-11-01. ⟲