As Três Perguntas Que Determinam a Necessidade de Multi-Org
O erro comum é abordar a questão "um Org ou vários?" como uma questão técnica de capacidade ou performance. Na maioria dos casos, a resposta técnica existe dentro de um único Org: Record Types, Profiles, Permission Sets e Sharing Rules são suficientes para separar unidades de negócios sem dividir o ambiente em si. O Salesforce suporta dezenas de milhares de usuários e milhões de registros em um único Org — a capacidade quase nunca é a verdadeira razão para a divisão.
A questão que realmente importa é uma questão de independência organizacional, e se desdobra em três testes:
- Independência Regulatória Genuína — Existe um requisito legal ou contratual para a separação física dos dados (por exemplo, uma entidade legal separada com regulamentação local que proíbe o compartilhamento de infraestrutura), diferentemente da separação lógica que pode ser alcançada com o Sharing Model.
- Ritmo de Mudança Incompatível — Uma unidade de negócios precisa de ciclos de Release frequentes e rápidos, enquanto outra exige máxima estabilidade e auditoria rigorosa, de modo que cada Release compartilhado se torne um ponto constante de atrito entre as equipes.
- Modelo de Dados Conflitante no Núcleo, e não apenas diferente — Quando uma mesma entidade (por exemplo, "Cliente" ou "Pedido") possui uma definição de campo obrigatório, um fluxo de aprovação ou uma estrutura de relacionamentos que é fisicamente contraditória entre as unidades, e não apenas diferente na exibição.
Se nenhuma das três condições for claramente atendida, a solução correta é um único Org com separação lógica. A divisão "por segurança" cria um custo operacional fixo — duplicação na gestão de usuários, duplicação de licenciamento e duplicação na manutenção de integração — em troca de um problema que poderia ser resolvido com configuração.
Matriz de Decisão: Um Org versus Vários Orgs
| Dimensão | Um Org com Separação Lógica | Vários Orgs Separados |
|---|---|---|
| Custo de Licenciamento e Manutenção | Mais baixo — uma licença, gestão centralizada | Mais alto — duplicação de licenças, duplicação na gestão de Release |
| Customer 360 e Visão Unificada | Natural — todos os dados no mesmo espaço | Requer camada de BI ou integração dedicada |
| Independência Operacional por Unidade | Limitada — cada Release afeta todos | Completa — cada unidade controla seu ritmo |
| Conformidade Regulatória Estrita | Não aplicável se a exigência for física | A única opção que atende ao requisito |
| Complexidade da Integração Interna | Baixa | Alta — exige Middleware ou ETL |
| Risco em Fusões/Cisões Futuras | Baixo — apenas alteração de permissões | Alto — projeto de migração completo |
Conclusão: a opção padrão deve ser um único Org, e a divisão só deve ser escolhida quando houver uma resposta positiva e clara para uma das três perguntas acima, e não como uma reação a um atrito organizacional temporário.
O Que Acontece na Prática ao Dividir Sem Razão Suficiente
Quando uma organização divide um Org por razões políticas (uma unidade que busca "seu próprio controle") e não por razões técnicas reais, três coisas acontecem dentro de um ou dois anos: primeiro, ocorre a duplicação de registros de clientes em cada Org onde a mesma entidade de negócios aparece, sem uma chave de identificação compartilhada. Segundo, cada mudança em nível organizacional (como a atualização de um processo de segurança ou a implementação de uma nova ferramenta) se torna um projeto separado em cada Org, o que dobra o custo de qualquer mudança futura. Terceiro, o reporting em nível de empresa exige uma camada de integração que não era necessária inicialmente, e muitas vezes é construída sob pressão após a descoberta do problema, em vez de fazer parte do planejamento.
Portanto, um dos princípios orientadores na arquitetura Salesforce é primeiro verificar se a necessidade organizacional pode ser atendida com permissões e Sharing Rules dentro de um único Org, e só então considerar a divisão.
Roteiro Gradual para Quem Já Precisa Dividir
Quando uma das três condições realmente ocorre, a divisão deve ser realizada em uma ordem que minimize o risco:
1. Defina Uma Chave de Identificação Global Antes da Divisão
Antes de criar um segundo Org, estabeleça um campo identificador unificado (número de CNPJ, Customer ID global ou código similar) que permitirá, no futuro, a correspondência de registros entre os ambientes. Sem isso, qualquer tentativa futura de unificar a visão do cliente será baseada na correspondência de nome e endereço, o que gera erros em grande escala.
2. Escolha um Padrão de Integração de Acordo com a Direção e o Ritmo dos Dados
Se o objetivo for apenas atualizações periódicas para fins de reporting, um ETL agendado é suficiente. Se for necessária uma visão em tempo real (por exemplo, para verificação de crédito entre unidades), uma API síncrona com tratamento de falhas e retries será indispensável. A escolha do padrão inadequado é a principal causa de falhas em integrações Cross-Org sob carga — mais detalhes sobre o tema em Padrões de Integração Salesforce.
3. Planeje Credenciais e Permissões de Acesso Antecipadamente
Usuários que trabalham em ambos os Orgs (por exemplo, gerentes de contas globais) exigem uma solução de Identity gerenciada uma única vez, e não dois usuários separados com duas senhas. O planejamento de SSO entre Orgs evita que cada alteração nas permissões de um usuário seja realizada manualmente em dois ambientes — o tópico é detalhado em Arquitetura de SSO e Identity no Salesforce.
4. Teste os Limites da API Antes que a Integração Entre em Produção
Toda chamada entre dois Orgs é contabilizada na cota da API de ambos os lados. Um tráfego planejado sem teste de volume pode exceder os limites diários justamente em picos de demanda, ou seja, precisamente quando a integração é mais necessária. Isso deve ser verificado antecipadamente com os Limites e Resiliência da API Salesforce.
5. Defina um Owner e um Processo de Governança Comum para Ambos os Orgs
Alguém precisa ser responsável pela consistência das decisões arquitetônicas entre os ambientes — estrutura de campos, convenções de nomenclatura e políticas de mudança. Sem uma propriedade centralizada, os dois Orgs se desviarão também em nível de padrões dentro de um ano, tornando qualquer integração futura mais cara.
Cenário Ilustrativo: Um Grupo Segurador com Duas Divisões
Este é um cenário hipotético e destina-se apenas a fins ilustrativos. Um grupo segurador possuía uma divisão de seguros gerais e uma divisão de seguros de vida, ambas operando sob a mesma entidade legal, mas com reguladores diferentes e ciclos de aprovação de produtos significativamente distintos. A divisão de seguros de vida exigia controle de mudanças rigoroso com aprovação regulatória para cada Release, enquanto a divisão de seguros gerais desejava lançar melhorias em ritmo semanal.
A proposta inicial era dividir para um Org separado para cada divisão, mas a análise com base nas três perguntas revelou que apenas o ritmo regulatório (teste 2) era realmente aplicável — o modelo de cliente e produto não conflitava (teste 3 negativo), e não havia exigência de separação física de dados (teste 1 negativo). A solução escolhida foi um único Org com dois "caminhos de Release" separados dentro do mesmo ambiente — um Sandbox dedicado e um processo de aprovação separado para a divisão de seguros de vida, utilizando um modelo de dados comum para um único Customer 360. A divisão completa foi evitada, assim como os custos de manutenção duplicados que teriam de ser arcados por anos.
Riscos Comuns e Como Evitá-los
- Divisão "Temporária" que se Torna Permanente — Um Sandbox que se transforma em ambiente de produção sem passar por auditoria de segurança. Previne-se garantindo que todo Org com dados reais de clientes passe por um processo formal de aprovação de Governança, sem exceções.
- Registros Duplicados Sem Chave Comum — Ocorre quando a divisão acontece antes da definição de um identificador global. Previne-se estabelecendo o campo comum como pré-requisito para a divisão, e não como uma etapa posterior.
- Cota da API Atingida em Picos de Carga — Acontece quando a integração entre Orgs é planejada com base no volume médio, e não no volume de pico. Prevene-se com testes de carga antes da entrada em produção e a construção de um mecanismo de Backoff.
- Desvio de Padrões entre Orgs — Ocorre quando não há um único Owner para a arquitetura compartilhada. Prevene-se definindo um pequeno comitê de Governança que aprova mudanças na estrutura de dados em ambos os lados.
- Relatórios Gerenciais Não Confiáveis — Acontece quando se tenta calcular KPIs inter-organizações diretamente do Salesforce sem uma camada de unificação. Prevene-se estabelecendo uma camada de BI dedicada desde o primeiro dia da divisão, e não como um projeto de correção tardio.
Conclusão
A opção padrão é um único Org; a divisão é uma exceção que requer justificativa concreta em um dos três testes — independência regulatória genuína, ritmo de mudança incompatível ou modelo de dados fisicamente conflitante. Quando a justificativa existe, o sucesso da transição é medido pela preparação feita antes da divisão: chave de identificação global, padrão de integração adequado, identidade compartilhada, teste de limites da API e ownership claro sobre padrões comuns. Uma organização que salta essa preparação não economiza trabalho — apenas o adia para um momento em que a correção será muito mais cara.