A estratégia de orgs é uma decisão de panorama

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · 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

Módulo 5 de 6 do capítulo Entendendo os dados corporativos, capítulo 4 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Desenhe o panorama de sistemas · Próximo: O panorama da Steve Trucking

A pergunta que este módulo responde: Uma org ou várias, e onde ela roda?

Quando ensino candidatos a CTA, digo que a maior decisão de um cenário vem nos primeiros cinco ou dez minutos: com quantas orgs Salesforce estamos lidando? Uma org grande? Orgs regionais para América do Norte, EMEA e APAC? Orgs separadas para unidades de negócio separadas? Uma org especial para um país com regras próprias? E ligada diretamente a isso: onde essas orgs rodam?

Esses não são detalhes de administração. Eles mudam onde os dados vivem, as integrações, os relatórios, a identidade, e como as pessoas pelo mundo chegam ao sistema. É por isso que trato a estratégia de orgs como uma decisão de panorama, e por que a tomo primeiro.

Comece com uma org

Minha posição de partida é simples: comece com uma org. Não porque uma org seja sempre o certo, mas porque preciso de um motivo para acrescentar outra. Uma org me dá um lugar para os dados de cliente compartilhados, um modelo de segurança, um lugar para fazer deploy, um conjunto de integrações, um lugar para os relatórios. E uma org ainda consegue sustentar unidades de negócio, países, processos, tipos de registro, aplicações, modelos de compartilhamento e experiências diferentes.

Então não acrescento uma org porque a Europa faz as coisas um pouco diferente, ou uma divisão tem seu próprio processo de vendas, ou as unidades de negócio não se gostam. Esses são requisitos, não fronteiras de org. A pergunta é: que força é forte o bastante para justificar outra org?

Várias orgs têm um custo

Divida uma org em três (América do Norte, Europa, Ásia-Pacífico) e você não desenhou três caixas arrumadas; criou perguntas novas. Onde vive um cliente global? E se ele opera em duas regiões: duas cópias, e qual delas é a dona? Como alguém faz relatórios globais? O ERP se integra com as três, o data warehouse recebe três feeds, o provedor de identidade se conecta às três? Fazemos deploy da mesma funcionalidade três vezes e mantemos três modelos de dados alinhados? Se um agente precisa de uma visão global de um cliente, a qual org ele pergunta?

Volte ao panorama do módulo 4. Uma caixa Salesforce vira três, e cada seta é redesenhada. Várias orgs não é errado. Nunca é de graça.

Procure fronteiras reais

O que pode justificar outra org? Fronteiras reais o bastante para moldar a arquitetura: residência de dados, regulação, separação legal, modelos operacionais realmente diferentes, uma aquisição que ainda não convergiu, uma restrição regional de hospedagem, uma governança muito diferente, às vezes escala ou isolamento. A lista não está completa. O ponto é distinguir “estes grupos são diferentes” de “estes grupos precisam de uma fronteira de arquitetura”. A segunda barra é muito mais alta.

Geografia não é automaticamente uma estratégia de orgs

“Operamos em 30 países, então precisamos de 30 orgs.” Não. A geografia importa quando traz um requisito de arquitetura. Uma empresa pode ter usuários no mundo todo numa arquitetura comum. Então não conto países; pergunto o que vem com eles. Onde os dados podem ser armazenados? Onde podem ser processados? Há limites para mover dados pessoais através de fronteiras? Promessas contratuais sobre residência? Uma região precisa de outro serviço ou de outro host Salesforce? “Há um escritório na Alemanha” não basta por si só.

A hospedagem faz parte do desenho

Aqui a plataforma moderna torna o panorama mais interessante. O Hyperforce roda o Salesforce em infraestrutura de nuvem pública em regiões ao redor do mundo, dando aos clientes mais escolha e controle sobre onde seus dados residem (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), em inglês). Então, quando rotulo uma caixa como “Salesforce, Europa”, essa localização pode importar.

Mas seja preciso. Escolher onde uma org vive não é uma promessa de que cada byte de cada serviço fica lá. A Salesforce orienta os clientes a revisar a documentação de confiança e conformidade do Hyperforce, incluindo os suboperadores adicionais dos serviços que compram (mesma fonte). Então não diga “estamos no Hyperforce no país X, então tudo fica no país X”. Saiba quais serviços você está realmente usando, e qual requisito está atendendo. E repare no que você escolhe: a região, não a nuvem por baixo dela. O Hyperforce roda na AWS, com o Google Cloud a partir do fim de 2026, e é a Salesforce que decide em qual provedor uma org fica; um cliente com um motivo regulatório documentado para evitar um deles conversa com a sua equipe de conta (mesma fonte).

Não brinque de advogado

É aqui também que os arquitetos precisam conhecer seu papel. Se alguém diz “a lei de privacidade europeia exige uma org separada”, não vou aceitar às cegas. Também não vou me nomear advogado da empresa e declarar que não exige. Vou perguntar: que requisito específico estamos atendendo? Onde os dados são armazenados, onde são processados, transferência internacional, quem pode acessá-los para suporte, um contrato, uma política interna? Depois trabalho com privacidade, segurança, conformidade e jurídico para transformar esse requisito em arquitetura. Não invente requisitos legais, e não os ignore. Traduza-os.

Quando a Europa ganha a sua própria org

Eis uma fronteira que vejo em cenários reais. Uma empresa tem uma presença forte nos EUA e uma presença forte na Europa: duas grandes bases de clientes, duas operações de vendas e atendimento, e um programa europeu de privacidade construído em torno do GDPR (RGPD). O GDPR não diz “você precisa de uma org Salesforce separada”. Ele estabelece regras para os dados pessoais, incluindo quando eles podem ser transferidos para fora da UE (GDPR, capítulo V (opens in a new tab)). Mas essa empresa, trabalhando com as suas equipes de privacidade e jurídica, decide que os dados pessoais dos seus clientes europeus devem viver numa org hospedada na Europa, operada pela sua equipe europeia, sob a sua governança europeia. Esse é um requisito real, e é deles, não meu.

Agora “uma grande org global” não é mais uma preferência. Há uma fronteira no panorama, Salesforce AMER e Salesforce EMEA, e eu preciso desenhá-la. E a segunda org nunca é só mais uma caixa.

Click to enlarge

Duas orgs, AMER e EMEA. O âmbar é o que a segunda org acrescenta: não mais uma caixa, mas todas as setas de novo.

Percorra as setas de novo

Com mais de uma org, percorra o panorama de novo. O ERP envia produtos para cada org? Cada uma devolve pedidos? Onde os clientes são mestres, e os dados deles podem cruzar regiões? A camada de integração é global ou regional? Qual provedor de identidade autentica quais usuários? Para onde vão os dados analíticos?

Três lugares mostram o custo mais rápido:

Relatórios. O CEO quer um pipeline global. Numa org, é um relatório do Salesforce. Em três, é um problema de relatórios corporativos: replicar, mandar para o data warehouse, federar? Quão atual precisa estar, e as orgs sequer definem “pipeline” do mesmo jeito? Onde a análise vive segue onde os dados vivem, e se você divide os dados operacionais de propósito, precisa projetar como os insights voltam a se juntar.

Dados mestres. Um cliente global compra nos EUA, na Alemanha e no Japão. Três orgs, então provavelmente três Contas. Como você sabe que são a mesma empresa? Qual é o identificador global, e quem é o dono? Se uma região muda o endereço, a mudança deve se espalhar? Quais atributos são globais e quais regionais? A estratégia de orgs não resolve a identidade; ela muda o problema de identidade. Isso é o capítulo 6.

Integração. Uma org: o Salesforce, a camada de integração, o ERP. Três orgs: três conexões com a camada de integração, talvez uma com host e conectividade próprios, alguns fluxos compartilhados, alguns regionais, alguns dados podendo cruzar e outros não. Até a rede pode mudar: se a empresa precisa de conectividade privada dedicada ao Hyperforce (na AWS, a Salesforce recomenda o AWS Direct Connect; mesmo FAQ do Hyperforce), cada org e cada host no desenho é mais uma conexão a planejar. Onde uma org roda pode mudar como o resto da empresa chega até ela.

Uma org ou várias é uma decisão que você toma agora, no início, no panorama. Como as orgs depois compartilham dados (Salesforce Connect entre orgs, integração entre elas, Data 360) é a mecânica, e o capítulo 14, Uma org ou várias? (coming soon), trata disso.

Se você projeta todo o modelo de dados e a arquitetura de integração e só então ouve “aliás, isto precisa ser três orgs”, você não fez um pequeno ajuste. Mudou a arquitetura. É por isso que a decisão vem primeiro.

Não divida só para deixar as caixas menores

Uma org grande parece complicada: muitas unidades, objetos, usuários, integrações. Alguém diz: “Não seria mais limpo se cada um tivesse sua própria org?” O desenho pode ficar mais limpo. A empresa talvez não. Você trocou complexidade interna por complexidade distribuída: sincronização, dados duplicados, identidade entre orgs, relatórios globais, vários pipelines de release, integrações e automação duplicadas, e governança sobre tudo isso. Às vezes essa ainda é a troca certa. Mas separado não é o mesmo que simples.

E uma org também não é de graça. A governança compartilhada importa mais, as equipes podem afetar umas às outras, as fronteiras de segurança precisam de design cuidadoso, o modelo de dados precisa servir muitos grupos, os releases precisam de coordenação, e regras regionais podem restringir todo mundo. Então não é “o Steve diz que é sempre uma org”. Minha inclinação de partida é uma org; depois procuro o requisito forte o bastante para me tirar dela.

Torne a decisão visível

Se a estratégia de orgs importa, não desenhe uma nuvem Salesforce genérica. Desenhe as orgs e rotule-as (AMER, EMEA, o que for real), anote o requisito de hospedagem ou residência por trás de cada uma, e percorra as conexões. Outro arquiteto deve conseguir ver por que cada fronteira existe. Se não consigo explicar por que há três caixas Salesforce, não terminei a decisão.

A Steve Trucking roda uma org, nos EUA, e nada no briefing dela pede outra. Mas guarde este módulo para o projeto final: uma aquisição que chega com sua própria org é exatamente o tipo de fronteira que testa essas perguntas.

Além do exame: o que a IA muda. Um agente pode tornar uma fronteira de org invisível para o usuário. Por baixo, a arquitetura ainda precisa decidir a qual org ou sistema o agente pode perguntar, quais dados podem cruzar regiões, e qual resposta tem autoridade. A IA pode esconder a complexidade na experiência; ela não remove a governança nem a fronteira.

O que um arquiteto decide aqui

• Se há um motivo real de arquitetura para mais de uma org, em vez de resolver as diferenças dentro de uma.
• Onde cada org roda, e qual requisito de residência, regulatório, contratual ou de negócio a coloca ali.
• Quais dados podem cruzar fronteiras de org e de região, onde os dados mestres têm autoridade, e como funciona a identidade global.
• Como a integração, a identidade, a análise e os relatórios mudam quando uma caixa Salesforce vira várias.
• Se o benefício da separação vale a arquitetura distribuída que ela cria.

Quando leio um cenário, procuro esta decisão primeiro: uma org ou várias, hospedadas onde, e forçadas por quê? Responda a isso, e o resto do panorama começa a tomar forma.

Para saber mais

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (em inglês), consultado em 2026-10-14.
• EUR-Lex, Regulamento (UE) 2016/679, o Regulamento Geral sobre a Proteção de Dados (opens in a new tab), capítulo V (transferências de dados pessoais para países terceiros), consultado em 2026-10-14.