Arquitetura Salesforce para Empresas: Como Planejar um Sistema Escalável

A Resposta Curta

Uma boa arquitetura Salesforce não se mede pela quantidade de componentes construídos, mas sim pela capacidade da organização de adicionar um novo negócio, produto ou mercado sem desmantelar o que já funciona. O problema mais comum que observamos não é uma escolha tecnológica equivocada, mas sim a ausência de uma camada de decisões documentada: quem é o proprietário de cada objeto, por que o Flow foi escolhido em vez do Apex, e por que existem cinco integrações separadas em vez de uma única camada de Middleware.

Este artigo divide a arquitetura em seis camadas que devem ser planejadas em conjunto, e não isoladamente: Modelo de Dados e Objetos, Compartilhamento e Permissões, Automação, Integrações, Estratégia de Org e DevOps com Escalabilidade. O contexto estendido sobre o tratamento de erros de integração pode ser encontrado em Monitoramento de Erros de Integração Salesforce.

Modelo de Dados e Objetos: A Base de Tudo

Um erro comum em muitas organizações: criar um novo Custom Object para cada requisito de negócio, sem verificar se é possível usar um campo adicional em um objeto existente ou um Record Type. O resultado, após dois ou três anos, é uma Org com 80 a 120 objetos personalizados, alguns com significado duplicado, e sem documentação do motivo de cada criação.

O princípio orientador antes de criar qualquer objeto é perguntar: quem é o proprietário do negócio, qual é a fonte da verdade (Salesforce ou sistema externo) e o que acontece quando um registro é excluído ou duplicado. Empresas que gerenciam um catálogo de produtos complexo, por exemplo, tendem a criar um Objeto separado para cada categoria em vez de usar Record Types em Product2 – o que gera uma sobrecarga de manutenção desnecessária a cada atualização.

Tabela útil para verificar a maturidade do modelo de dados:

Compartilhamento e Permissões: A Camada que Quebra Silenciosamente

Um modelo de permissões frouxo não é detectado imediatamente — ele é descoberto quando alguém vê um dado que não deveria ver, ou quando um relatório gerencial exibe menos linhas do que o esperado porque uma Sharing Rule bloqueia o acesso. A escolha entre Role Hierarchy, Organization-Wide Defaults, Sharing Rules e Permission Sets deve ser derivada da estrutura organizacional real, e não da estrutura hierárquica oficial no organograma.

Um antipadrão comum: conceder "View All" ou "Modify All" no nível do perfil para "resolver" um problema de permissão sob pressão de tempo, sem revisitar e restringir posteriormente. Isso funciona no curto prazo e cria uma ampla exposição de dados no longo prazo — especialmente em setores regulamentados como finanças ou saúde. Permission Set Groups permitem construir permissões modulares que podem ser adicionadas e removidas sem tocar no perfil base, sendo uma forma mais segura de lidar com uma organização em crescimento.

Criteria-Based Sharing Rules em objetos com milhões de registros exigem um teste de carga antes da produção — em alguns casos, uma regra de Compartilhamento aparentemente inofensiva causa um Recalculation que dura horas e paralisa processos noturnos.

Automação: Flow versus Apex

A questão "Flow ou Apex" não é uma questão de gosto, mas de complexidade, volume e ciclo de vida. O Flow é mais legível para uma equipe operacional, é construído e mantido rapidamente, e é adequado para lógicas de negócio que mudam. O Apex é necessário quando há processamento em massa (Bulk Processing) de milhares de registros em uma única transação, quando é preciso controle preciso da ordem de execução em relação a outros Triggers, ou quando é exigida testagem automatizada (Test Coverage) para fins regulatórios ou de Gerenciamento de Mudanças formal.

Um antipadrão comum em organizações em crescimento: cadeias de Flow que chamam umas às outras (Flow que aciona Flow que aciona Flow), sem um mapa central que mostre a ordem de execução. Quando algo quebra, ninguém sabe qual Flow foi executado primeiro. Exemplo prático: uma organização com 14 Flows ativos em Opportunity, três deles com a mesma lógica de atualização de status, escritos em diferentes períodos por pessoas diferentes sem verificar o que já existia.

Uma regra prática: se houver mais de 5 a 6 condições ramificadas em uma única lógica de negócio, ou se for necessária uma chamada externa dentro de um loop, o Apex é preferível. Fora isso, o Flow é preferível porque é acessível para manutenção mesmo quando o desenvolvedor original não está mais na empresa.

Integrações: Do Ponto-a-Ponto a uma Camada Gerenciada

Uma organização que começa com duas conexões externas (ERP e um sistema de pagamento, por exemplo) geralmente as constrói diretamente, ponto a ponto, o que é razoável nesta fase. O problema começa quando se adicionam uma terceira, quarta e quinta conexão — cada uma com sua própria lógica de Retry, tratamento de erros e mapeamento de campos, sem um padrão comum. Nesta fase, qualquer mudança no sistema fonte quebra uma ou mais conexões sem que ninguém saiba de antemão.

A transição para uma camada de Middleware (MuleSoft, ou uma camada de integração personalizada) não precisa ser um projeto gigantesco — pode-se começar pela conexão mais frágil ou mais cara de manter e migrar gradualmente. Princípios a serem adotados em cada nova integração: Idempotência (uma chamada duplicada não cria um registro duplicado), External ID para identificação segura e um log que permita reconstruir exatamente o que aconteceu em cada chamada. Mais detalhes sobre padrões de integração podem ser encontrados em Conectando Salesforce ao ERP e Padrões de Integração Salesforce.

Estratégia de Org: Single Org, Multi-Org ou Segmentação por Unidade de Negócio

Esta é uma das decisões mais caras de mudar retrospectivamente. Uma Single Org com Segmentação por Unidade de Negócio (usando Record Types, Sharing e Permission Sets para separação lógica) é adequada para a maioria das organizações, pois mantém uma única fonte da verdade e métricas de relatórios unificadas. Uma Multi-Org é apropriada quando as unidades de negócio exigem modelos de permissão fundamentalmente conflitantes, quando há uma fusão ou aquisição que traz uma Org existente, ou quando a carga de permissões real afeta o desempenho.

A transição entre os modelos depois que a organização já está estabelecida é um projeto pesado — fusão de dados, remapeamento de permissões e, às vezes, perda de histórico. Um detalhamento completo dos aspectos a serem considerados na decisão está em Salesforce Multi Org.

DevOps e Escalabilidade: Como Manter a Capacidade de Mudança

Uma organização que desenvolve diretamente em Produção, sem Sandboxes organizados e sem ferramentas de CI/CD (como Copado, Gearset ou SFDX), rapidamente chega a um ponto em que qualquer mudança é arriscada. Um processo DevOps adequado inclui pelo menos um Sandbox para desenvolvimento, um Sandbox para testes, controle de versão para Metadata e um processo de Deployment automatizado com testes de regressão.

Tabela de decisões arquitetônicas centrais e suas implicações a longo prazo:

Cenário Organizacional de Exemplo

Uma empresa de distribuição com três unidades de negócios operou por quatro anos em uma única Org, com cada unidade adicionando objetos, Flows e integrações conforme a necessidade imediata. Quando a gerência decidiu adicionar uma quarta unidade, descobriu-se que não havia um único documento explicando quem era o proprietário de cada objeto, e três integrações diferentes sincronizavam clientes com o sistema financeiro com lógicas conflitantes.

A equipe de arquitetura realizou um mapeamento completo: identificou 23 objetos sem um proprietário claro, seis cadeias de Flow sobrepostas e duas integrações que criavam registros duplicados devido à falta de um External ID consistente. A solução não foi a reconstrução, mas sim a documentação gradual, a unificação da lógica de Compartilhamento sob Permission Set Groups e a migração de integrações críticas para uma única camada de Middleware. Em dois trimestres, o tempo para adicionar uma nova unidade de negócio diminuiu de vários meses para cerca de seis semanas.

Antipatterns Comuns em Organizações em Crescimento

• Custom Object para cada solicitação - Cria-se um novo objeto sem verificar a existência de um similar.
• Permissões amplas "temporárias" - Concedidas sob pressão e nunca mais restritas.
• Flow-in-Flow sem mapeamento - Cadeias de automação sem um diagrama de execução central.
• Point-to-Point sem Governança - Cada nova conexão é construída separadamente, sem um padrão comum.
• Desenvolvimento em Produção - Mudanças diretas sem Sandbox, testes ou Controle de Versão.
• Ausência de External ID - Sincronização por nome ou e-mail que cria registros duplicados.

Checklist para Avaliação da Maturidade da Arquitetura

• ☐ Cada Custom Object possui um proprietário de negócio documentado.
• ☐ O modelo de Compartilhamento foi testado sob cargas de dados realistas.
• ☐ Existe um mapa central de todas as cadeias de Automação.
• ☐ Cada integração possui External ID, Retry e log de erros.
• ☐ Existe um processo Sandbox-to-Production organizado com testes de regressão.
• ☐ A decisão entre Single Org e Multi-Org foi explicitamente tomada e documentada.
• ☐ Os Governor Limits são verificados em relação à projeção de crescimento para três anos.

Quando a arquitetura Salesforce exige orientação profissional e não apenas uma estrutura de trabalho autônoma, essa é a área de Serviços de Arquitetura de CRM.

Fontes Profissionais

• Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
• Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
• HPI Pro – Arquitetura de CRM — https://hpi.pro/crm-architecture
• HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data