O volume encontra o modelo de partilha

🌐 Também em 19 idiomas

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

Imagem gerada com IA

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

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

A pergunta que este módulo responde: Como um modelo que respeita a partilha 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 trabalho é um problema de volume. Nove milhões de ordens de trabalho, cada uma visível exatamente para os utilizadores internos certos e exatamente para o parceiro retalhista certo, é um problema de partilha com volume. Um registo não é só armazenado; o Salesforce também precisa de responder quem pode vê-lo? À escala, essa resposta faz parte da arquitetura de dados.

A partilha também é dado

Quando os arquitetos contam o volume, contam registos de negócio. Mas o Salesforce também mantém o que sustenta o acesso: proprietários, funções, grupos, regras de partilha, partilhas explícitas, 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 equipa de segurança resolve a partilha depois”. A relação que eu escolho, o proprietário, o pai, o modelo de utilizadores externos: cada um afeta a partilha. O arquiteto de dados e o arquiteto de partilha 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 num novo separador); Sharing a Record Using Apex (abre num novo separador)). 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 num novo separador), Winter ‘27, archived copy (abre num novo separador)). 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 num novo separador)). 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 funções não é um organograma

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

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

O recálculo da partilha é trabalho de verdade

A Steve Trucking muda o seu modelo operacional: centenas de utilizadores mudam de lugar, a propriedade muda, funções e grupos mudam, uma grande regra de partilha muda. Parece configuração. Mas a plataforma pode ter de recalcular o acesso numa grande população de registos, então eu trato isso como uma operação de dados. Quantos utilizadores, registos, mudanças de propriedade e de associação? Quanto recálculo? Podemos testar com o volume real? Quando deve correr, e o que os utilizadores 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 num novo separador)). 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 num novo separador), 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 suficiente para adiar a partilha, 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 utilizadores 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 registos de teste não prova nada sobre 50 milhões. Teste o Número de Zeros para o qual está realmente a projetar.

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 num novo separador)); 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 à escala

No Checkpoint 1, cada ordem de trabalho leva o seu parceiro retalhista, 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 trabalho da Redrock em cinco anos. A relação está certo; a Redrock realmente é um parceiro só. Então o design de acesso precisa de seguir a relação de negócio real (os utilizadores do parceiro veem as ordens de trabalho 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 partilha completamente diferentes, pode empilhar controlos de nível de campo num registo, 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.

A partilha tem o seu próprio Número de Zeros

Dois designs com 10 milhões de registos cada: um com propriedade simples, hierarquia estável, poucas regras de partilha e pouca rotatividade de associações; o outro com propriedade muito distribuída, funções que mudam com frequência, grandes grupos aninhados, muitas regras de partilha e reorganização constante. A mesma contagem de registos, 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 utilizadores externos, e o que acontece quando alguém muda de função, 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 demasiado amplo 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 relações, proprietários, funções, grupos e regras de partilha 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 registo.
• Como o acesso de parceiros, funcionários, aplicações e agentes continua ligado a relações de negócio, não a atalhos de identidade.

É fácil desenhar um design seguro para 1.000 registos, e um rápido em que toda a gente 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. À escala, a partilha faz parte da arquitetura de dados.

Para saber mais

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