Por que um modelo de compartilhamento reativo é mais difícil do que um bem planejado
O problema típico não é percebido no primeiro mês. Ele se manifesta quando um gerente de vendas regional nota que está vendo uma oportunidade de um território concorrente, ou quando um agente de serviço abre um caso de um cliente VIP que deveria ser acessível apenas a uma equipe dedicada. Ambos os cenários são resultado direto de uma ordem de trabalho invertida: objetos e campos são definidos, e somente no final se questiona quem deveria ver o quê.
O modelo de visibilidade no Salesforce é construído em camadas que funcionam juntas, não isoladamente: Organization-Wide Defaults (OWD) estabelece a linha de base mais restritiva, Role Hierarchy adiciona acesso vertical com base na estrutura gerencial, Sharing Rules abrem acesso horizontal baseado em critérios de negócio, Teams e Manual Sharing tratam de casos específicos, e Apex Managed Sharing entra em cena quando a lógica é muito complexa para ser expressa estaticamente. Essa ordem é crucial: qualquer camada escolhida prematuramente gera uma dívida que é difícil de desfazer, pois permissões já concedidas são percebidas como um direito adquirido.
O Mapa das Camadas e Quando Cada Uma é Apropriada
| Camada | O Que Resolve | Quando Escolher | Risco de Escolha Incorreta |
|---|---|---|---|
| OWD | Linha de base: quem não pode ver nada por padrão | Sempre definido, geralmente "Private" para objetos sensíveis | OWD muito aberto torna outras camadas redundantes |
| Role Hierarchy | Acesso vertical do gestor às informações dos subordinados | Quando a estrutura de gestão reflete a necessidade de supervisão de dados | Hierarquia "política" que não corresponde à propriedade real dos dados |
| Sharing Rules | Abertura de acesso horizontal por critério fixo (função, grupo, valor de campo) | Equipe inter-hierárquica que precisa de acesso ao mesmo tipo de registro | Múltiplas regras sobrepostas, dificultando saber quem concedeu o acesso |
| Public Groups | Agrupamento de usuários para compartilhamento, independente da hierarquia | Quando um grupo de trabalho não corresponde a uma única função organizacional | Grupos não atualizados quando um colaborador muda de função |
| Account/Case Teams | Acesso variável em um único registro, conforme a composição da equipe | Quando cada cliente ou caso possui uma equipe única e variável | Manutenção manual que é esquecida quando a equipe muda |
| Territory Management | Atribuição de acesso baseada em regras dinâmicas e multidimensionais | Atribuição variável por várias características simultâneas, acesso paralelo para vários representantes | Complexidade de manutenção que não se justifica abaixo de um certo limite organizacional |
| Apex Managed Sharing | Compartilhamento derivado de lógica dinâmica que não pode ser expressa estaticamente | Critério que depende de cálculo, evento externo ou combinação de campos | Código sem monitoramento que continua a executar após a mudança da necessidade de negócio |
OWD: A Decisão que Define Tudo o Mais
O OWD não é apenas uma configuração de segurança técnica — é uma declaração organizacional sobre quem é o proprietário principal da informação. A regra prática: defina o OWD para o estado mais restritivo que seja realmente necessário, e a partir daí, expanda o acesso usando Sharing Rules, e não o contrário. A razão: expandir o acesso pontual é fácil e documentado, enquanto restringir o acesso já existente exige comunicação organizacional, pois os usuários percebem a perda de acesso como um prejuízo, mesmo que seja a correção de um erro histórico.
Um ponto que nem sempre recebe atenção suficiente: o OWD é definido separadamente para cada objeto, e objetos dependentes (Master-Detail) herdam a visibilidade do objeto principal. Ao construir um novo modelo de dados, é essencial verificar a cadeia de dependência completa antes de definir o OWD — caso contrário, um objeto "secundário" inadvertidamente definido como Público pode expor informações do objeto principal.
Hierarquia de Funções Versus Estrutura Gerencial Real
O erro mais comum é replicar o organograma na Role Hierarchy tal como ele é, sem verificar se ele também reflete o fluxo de propriedade dos dados. Um gerente regional precisa ver as oportunidades de sua equipe — esta é uma função gerencial. Mas um CFO não precisa ver automaticamente todos os casos de serviço apenas por estar em uma posição superior na hierarquia geral; se houver tal necessidade, ela deve ser resolvida por uma Sharing Rule direcionada, e não por uma hierarquia excessivamente ampla.
Uma hierarquia de compartilhamento separada da hierarquia de relatórios organizacional é uma solução legítima e, por vezes, preferível, especialmente em organizações com uma estrutura matricial onde os relatórios gerenciais não se alinham com a propriedade dos dados do cliente.
Matriz de Decisão: O Que Ativa Cada Mecanismo de Compartilhamento
- A necessidade varia por função fixa e previsível → Role Hierarchy.
- A necessidade é compartilhada por um grupo de trabalho que transcende funções → Public Group + Sharing Rule.
- A necessidade varia conforme a composição da equipe em um único registro → Account Team ou Case Team.
- A necessidade depende de uma combinação de condições dinâmicas (geografia, produto, porte do cliente) → Territory Management.
- A necessidade deriva de um cálculo, evento externo ou condição que não pode ser expressa estaticamente → Apex Managed Sharing.
- A necessidade é uma exceção pontual e temporária para um único registro → Manual Sharing, com supervisão e documentação.
Esta matriz deve ser elaborada antes de iniciar o trabalho nas ferramentas, e não em paralelo — caso contrário, um mecanismo será escolhido com base no que é familiar à equipe de desenvolvimento, e não no que é mais adequado à necessidade.
Cenário Ilustrativo: Fabricante de Equipamentos Industriais com Três Canais de Venda
Considere um fabricante hipotético de equipamentos industriais com aproximadamente 180 usuários Salesforce, operando por meio de três canais: venda direta por região geográfica, venda por meio de distribuidores e venda para contas estratégicas globais gerenciadas em paralelo por vários representantes em diferentes países.
A tentativa inicial de usar apenas a Role Hierarchy falhou: uma conta estratégica global não pertence a uma única hierarquia regional, e um representante na Alemanha não via as atualizações de seu colega no Brasil na mesma conta. A solução escolhida combinou três camadas: OWD em Account e Opportunity foi definido como “Private”; a Role Hierarchy foi usada para o acesso gerencial padrão dentro de cada região; e para contas estratégicas, um Account Team dinâmico foi configurado para ser atualizado automaticamente via Flow quando o campo "Strategic Account Owner Region" fosse alterado. Os distribuidores receberam acesso separado por meio de uma Sharing Rule baseada em um Public Group dedicado, para não serem expostos às contas de venda direta.
Resultado: O tempo de Recálculo de Compartilhamento permaneceu estável, pois a maior parte do acesso deriva de uma estrutura constante (Role, Public Group) e apenas uma minoria das contas — as estratégicas — depende de atualizações dinâmicas. A principal lição: não existe um único mecanismo "certo" para toda a organização; é preciso adaptar o mecanismo ao tipo de dependência de cada subconjunto de registros. Mais detalhes sobre a escolha de padrões de integração e um modelo de dados de suporte estão disponíveis no Guia de Arquitetura de CRM.
Riscos Específicos do Planejamento de Visibilidade e Ações Preventivas
| Risco | Como se Manifesta na Prática | Ação Preventiva |
|---|---|---|
| OWD aberto "temporariamente" na fase piloto | A abertura permanece mesmo após o sistema entrar em produção plena | Definir uma data de fechamento prévia e documentá-la como um item de Go-Live, não como recomendação |
| Múltiplas Sharing Rules sobrepostas | Impossibilidade de saber com certeza por que um usuário vê um registro específico | Nomenclatura padrão para cada regra, incluindo a razão de negócio, e revisão periódica de regras não usadas |
| Apex Sharing sem testes de execução sob carga | Cálculo de compartilhamento que atrasa com o aumento do volume de dados | Executar teste de carga no Recálculo de Compartilhamento antes de dobrar o volume de registros em produção |
| Hierarquia de compartilhamento copiada de hierarquia organizacional política | Gerentes veem dados para os quais não têm necessidade de negócio | Separar a hierarquia de funções para fins de compartilhamento da hierarquia de relatório oficial, quando não forem idênticas |
| Manual Sharing acumulado sem proprietário | Permissões excepcionais permanecem após a razão para o compartilhamento não ser mais relevante | Processo de expiração ou revisão trimestral de compartilhamentos manuais |
| Mudança de função do usuário sem atualização de grupos públicos | Acesso antigo permanece aberto e novo acesso está ausente | Integrar a atualização de grupos e funções como uma única etapa no processo de mudança de status do colaborador |
Checklist Antes de Finalizar o Modelo de Compartilhamento
- ☐ OWD configurado de acordo com a condição mais restritiva exigida, não pela conveniência da fase de desenvolvimento.
- ☐ A cadeia de dependência entre objetos Master-Detail foi verificada em relação ao OWD do objeto principal.
- ☐ A Role Hierarchy foi verificada em relação à propriedade real dos dados, e não apenas em relação ao organograma.
- ☐ Toda Sharing Rule possui uma razão de negócio documentada e um proprietário responsável por sua validade.
- ☐ Verificado se o Territory Management é realmente necessário ou se representa uma complexidade desnecessária.
- ☐ O código Apex Sharing foi testado sob um volume de dados realista, e não apenas em um ambiente Sandbox pequeno.
- ☐ Existe um processo para atualização de grupos públicos e permissões em caso de mudança de função ou desligamento.
- ☐ Uma frequência de revisão periódica foi definida para Manual Sharing e Sharing Rules inativas.
- ☐ O impacto do modelo de compartilhamento no desempenho de relatórios e execuções de Batch grandes foi avaliado.
- ☐ Existe um plano de resposta para o caso de uma exposição excessiva ser descoberta em produção.
Como Saber se o Modelo Suporta a Carga
A primeira métrica é o tempo de Recálculo de Compartilhamento após uma mudança estrutural — um aumento consistente ao longo do tempo indica que o modelo está se aproximando de uma complexidade não planejada. A segunda métrica é o número de solicitações de suporte do tipo "não tenho acesso" versus "tenho acesso desnecessário" — uma proporção que pende drasticamente para um lado sugere que o OWD ou as Sharing Rules não estão calibrados corretamente. A terceira métrica, especialmente importante em organizações com múltiplos sistemas, é a consistência entre as permissões do Salesforce e as permissões em sistemas sincronizados — em particular quando se trata de arquiteturas de integração baseadas em eventos, conforme descrito no Guia de Arquitetura Orientada a Eventos no Salesforce.
Em organizações que utilizam múltiplos "Orgs", a questão do modelo de compartilhamento é muitas vezes interligada à pergunta sobre se é realmente necessário mais de um ambiente de produção — a discussão completa está em Salesforce Single Org versus Multi Org, e na escolha do padrão de integração correspondente no Guia de Padrões de Integração Salesforce.
Resumo
Um bom modelo de compartilhamento e visibilidade não é medido no dia do lançamento — ele é medido quando a organização cresce, quando um usuário muda de função e quando alguém pergunta "por que não estou vendo isso?". A maneira de chegar lá não é escolhendo uma única ferramenta e a aplicando a tudo, mas sim mapeando cada grupo de registros de acordo com seu tipo de dependência — fixa, horizontal, dinâmica ou excepcional — e escolhendo o mecanismo apropriado para cada um. OWD restrito por padrão, Role Hierarchy que reflete a verdadeira propriedade, Sharing Rules com uma razão documentada, e Apex Sharing apenas quando a lógica o justifica — essa é a combinação que se sustenta mesmo quando a organização dobra de volume e complexidade.