Integração Salesforce-ERP: Guia de Arquitetura, Padrões e Riscos

A Resposta Breve

A integração do Salesforce com o ERP geralmente falha, não por um problema técnico na conexão em si, mas por uma pergunta não feita de antemão: qual sistema é a fonte da verdade para cada entidade, e o que acontece quando a mensagem entre os sistemas se perde, chega duplicada ou em ordem incorreta? Este guia estrutura a decisão em três camadas — fonte da verdade, padrão de sincronização e tratamento de falhas — e mostra como escolhê-las com base em cenários de negócios reais, e não apenas no que a API permite.

A abordagem recomendada é começar pelas entidades (cliente, produto, pedido, fatura) e não pela ferramenta. Para cada entidade, define-se um proprietário, uma taxa de atualização razoável e quem está autorizado a modificar. A partir daí, derivam-se o padrão de sincronização, o tratamento de erros e o nível de monitoramento necessário.

Uma continuação natural da discussão sobre a integração do Salesforce com o ERP aparece em Arquitetura Salesforce.

Fonte da Verdade para Cada Entidade: A Pergunta que Precede Qualquer API

Antes de escolher um protocolo ou ferramenta de integração, é preciso responder a uma pergunta para cada entidade: qual sistema decide o que é verdadeiro em caso de conflito? Geralmente, o ERP é a fonte da verdade para estoque, lista de preços, faturas e transações financeiras, enquanto o Salesforce é a fonte da verdade para relacionamentos com clientes, oportunidades e atividades de vendas. O problema começa quando alguém assume tacitamente que as duas direções "se resolverão sozinhas" — e então surgem situações em que um representante de vendas altera o endereço de entrega no Salesforce enquanto o ERP já enviou a mercadoria para o endereço antigo.

A solução prática é um documento de mapeamento de entidades: para cada entidade (Account, Product, Order, Invoice), são especificados a fonte da verdade, a direção da sincronização (unidirecional ou bidirecional) e a frequência de atualização necessária. Quando há uma necessidade real de sincronização bidirecional — por exemplo, a atualização do status de pagamento que retorna do ERP para o registro da oportunidade — estabelece-se uma regra explícita para a resolução de conflitos, como "a última atualização com base no timestamp prevalece" ou "campo financeiro sempre segundo o ERP".

Padrões de Sincronização: Request-Reply, Batch e Event-Driven

Três padrões cobrem a maioria dos cenários reais. Request-Reply (Síncrono) é adequado quando um usuário do Salesforce aguarda uma resposta imediata — por exemplo, a verificação da disponibilidade de estoque antes da confirmação de um pedido. A vantagem é a simplicidade e a resposta imediata; a desvantagem é a dependência total da disponibilidade do ERP naquele momento e o impacto na experiência do usuário se a resposta for lenta.

Batch (Lote) é adequado para atualizações de grande volume que não são urgentes, como a sincronização noturna de uma lista de preços ou a importação de faturas do dia anterior. O padrão é mais resistente a falhas temporárias, mas significa uma latência de horas a um dia entre os sistemas — uma lacuna que deve ser aceitável para o negócio, não apenas para a equipe técnica.

Event-Driven (via Platform Events, Change Data Capture ou fila de mensagens externa) é adequado quando é necessária uma resposta quase imediata sem exigir dependência síncrona. Uma mudança de status de pedido no ERP emite um evento, e o Salesforce se atualiza quando estiver pronto — incluindo retry automático se estiver temporariamente indisponível. Este é o padrão mais flexível, mas também o mais complexo de configurar e monitorar.

Tabela de Seleção de Padrão por Cenário

Nesse contexto, a decisão sobre o tipo de sincronização está ligada também ao modelo de permissões e à propriedade dos dados — uma expansão sobre isso aparece em Salesforce Sharing and Visibility.

Middleware vs. Point-to-Point

Quando há apenas uma conexão entre o Salesforce e o ERP, uma conexão direta (Point-to-Point) usando REST API ou Named Credentials pode ser a solução mais rápida e barata. O problema começa quando um terceiro sistema se junta — um data warehouse, um sistema de transporte ou uma plataforma de pagamento — e então cada novo sistema requer a construção de sua própria lógica de transformação e tratamento de erros, duplicando o que já existe na conexão anterior.

Uma camada de Middleware (como MuleSoft, Boomi ou Workato) resolve isso centralizando a lógica: cada sistema se conecta uma vez ao Middleware, e o Middleware é responsável pela transformação, Retry, fila de mensagens e monitoramento centralizado. O custo é um componente de infraestrutura adicional que requer licença, manutenção e expertise especializada.

Regra prática: até duas ou três conexões estáveis e sem lógica complexa — Point-to-Point é razoável. A partir de três sistemas ou mais, ou quando há uma demanda de Governança centralizada (como monitoramento uniforme para todas as integrações na organização), o custo do Middleware se justifica quase sempre em um a dois anos.

Tratamento de Erros e Idempotência

O cenário mais perigoso na integração não é uma falha completa, mas uma falha parcial: a mensagem foi enviada, o ERP criou um pedido, mas a resposta para o Salesforce foi perdida devido a um Timeout. Se o sistema remetente tentar novamente de forma ingênua, um pedido duplicado é criado.

A solução é uma Idempotency Key — um identificador único criado no lado remetente e anexado a cada solicitação. O lado recebedor mantém um registro de identificadores já processados e recusa (ou retorna o resultado existente) se o identificador já existir. Princípios práticos adicionais:

• Cada integração crítica recebe um mecanismo de Retry com Backoff gradual, não uma tentativa imediata e repetida
• Mensagens que falharam repetidamente vão para uma Dead Letter Queue para revisão manual e não desaparecem silenciosamente
• O log de erros inclui a carga útil completa (Payload) da mensagem que falhou, para permitir a recuperação manual
• Um processo de Reconciliação diário ou semanal compara os sistemas e identifica lacunas que a sincronização "perdeu"

Sem uma Idempotency Key e um processo de Reconciliação robusto, qualquer problema de rede transitório se torna um problema de dados persistente, difícil de rastrear semanas depois.

Limitações de API, Segurança e Monitoramento

O Salesforce impõe limites diários ao número de chamadas de API (dependendo da licença e edição), e limites no tamanho da resposta e tempo de execução. Uma organização que sincroniza dezenas de milhares de registros por dia via REST comum, chamada por chamada, atingirá o limite rapidamente. A solução é o Bulk API 2.0 para atualizações de volume, e o Composite API para reduzir o número de chamadas em processos síncronos de várias etapas.

No lado da segurança, três princípios se repetem em cada projeto bem-sucedido:

1. O uso de Named Credentials e Connected Apps com OAuth, e não nomes de usuário e senhas fixos no código.
2. A permissão do "usuário técnico" da integração é restrita exatamente aos objetos e campos que precisa — não um Profile de administrador de sistema.
3. O tráfego sensível (números de cartão de crédito, detalhes de conta bancária) passa por uma camada de Middleware ou Tokenization, e não é armazenado como texto claro no Salesforce.

Para o monitoramento, é necessário configurar um Dashboard que apresente pelo menos três dados: taxa de mensagens bem-sucedidas versus falhas, tempo médio e mediano de resposta, e número de registros na Dead Letter Queue. Um alerta automático quando a taxa de falhas ultrapassa um limite definido (por exemplo, acima de 2% das mensagens por dia) impede que um problema acumulativo seja descoberto apenas quando um cliente reclama.

Essas decisões geralmente se baseiam em um trabalho fundamental anterior no campo da informação e permissões, descrito em Dívida Técnica Salesforce.

Processo de Trabalho Recomendado

1. Mapeie Entidades e Defina a Fonte da Verdade

Para cada entidade (cliente, produto, pedido, fatura), determine qual sistema é o decisivo em caso de conflito. Sem essa decisão, qualquer discussão sobre "qual a forma correta de sincronizar" ocorre no vácuo.

2. Escolha um Padrão de Sincronização com Base na Latência Real Necessária

Nem todo processo precisa de resposta imediata. A verificação de estoque antes da venda sim; a atualização noturna da lista de preços não. Adaptar o padrão à necessidade real economiza custos desnecessários de infraestrutura.

3. Decida entre Middleware e Point-to-Point

A decisão depende do número de sistemas conectados e da necessidade de Governança centralizada, não de uma preferência tecnológica pura.

4. Planeje Idempotency, Retry e Reconciação desde o Início

Estes não são "melhorias futuras", mas parte da Definição de Concluído (Definition of Done) para qualquer integração que lide com dinheiro, estoque ou pedidos.

5. Defina Permissões Mínimas para o Usuário Técnico

Um Profile dedicado, não uma permissão genérica de administrador de sistema. Qualquer alteração na permissão requer aprovação separada da alteração funcional.

6. Teste Cenários de Falha, Não Apenas o Caminho Feliz (Happy Path)

Executar um teste onde o ERP "cai" no meio de um processo e medir o tempo de recuperação e se ocorrem duplicações, revela problemas que não são visíveis em um ambiente de desenvolvimento tranquilo.

7. Estabeleça um Dashboard e um Processo de Reconciliação Periódico

O monitoramento técnico (o servidor está ativo) não é suficiente; é necessário monitoramento de negócios (o número de pedidos é igual em ambos os sistemas).

Cenário Organizacional de Exemplo

Uma empresa de comércio com cerca de 40 mil pedidos por mês conectou o Salesforce ao ERP usando chamadas REST síncronas diretas, sem Middleware. Durante um período de pico de vendas, a taxa de falhas nas chamadas de API aumentou drasticamente devido ao limite de chamadas diárias, e os pedidos que não puderam ser registrados no ERP simplesmente "desapareceram" — porque não havia Dead Letter Queue e nenhum alerta.

Após a análise, descobriu-se que faltavam três coisas: não havia Idempotency Key definida, resultando em tentativas repetidas que às vezes criavam pedidos duplicados; não havia transição para o Bulk API para atualizações de volume; e não havia um processo de Reconciliação que comparasse o número de pedidos em ambos os sistemas. A solução incluiu a transição para uma camada de Middleware com uma fila de mensagens, a substituição de parte das chamadas síncronas por Batch frequente e a adição de um Dashboard diário que mostrava as discrepâncias.

O resultado não foi "zero falhas" — isso é um objetivo irreal — mas sim um tempo de identificação de falha que diminuiu de semanas para horas, e um processo que permite corrigir uma discrepância no mesmo dia, e não depois que um cliente reclama.

Riscos Comuns e Ações Preventivas

Quem está em uma fase anterior ao planejamento da conexão pode encontrar informações complementares em Salesforce Flow ou Apex, principalmente na decisão sobre onde realmente reside a lógica de transformação.

Como Medir o Sucesso

É aconselhável escolher apenas três a quatro métricas para a primeira versão e medi-las também antes do lançamento para ter uma linha de base real para comparação, e não uma estimativa de memória.

Checklist Antes de Entrar em Produção

• ☐ Para cada entidade, uma fonte da verdade e uma regra para resolução de conflitos são definidas
• ☐ Um padrão de sincronização (Request-Reply, Batch ou Event-Driven) é escolhido para cada processo separadamente
• ☐ Foi decidido se é necessário Middleware ou se uma conexão direta é suficiente
• ☐ Existe uma Idempotency Key para cada operação que cria um registro financeiro
• ☐ Retry com Backoff e Dead Letter Queue são definidos para mensagens que falharam
• ☐ O consumo diário da cota de API foi verificado em relação ao volume esperado
• ☐ A permissão do usuário técnico é restrita apenas aos objetos e campos necessários
• ☐ Foi realizado um teste de falha parcial, não apenas o Happy Path
• ☐ Existe um Dashboard para monitoramento de negócios, não apenas técnico
• ☐ Um processo de Reconciliação periódico e um responsável são definidos

Notas Aprofundadas para Implementação e Manutenção

Nota do Arquiteto: Quando Alterar um Padrão Existente

Se um padrão Batch noturno foi escolhido inicialmente por simplicidade, mas o negócio começa a exigir uma atualização de estoque quase imediata, não há necessidade de "explodir" toda a arquitetura — pode-se aumentar a frequência para 15 minutos como estágio intermediário e mudar para Event-Driven somente quando ficar claro que isso também não é suficiente. Uma mudança gradual, acompanhada da medição da latência real, é preferível a uma decisão abrangente e prematura.

De uma perspectiva gerencial, o verdadeiro teste da integração do Salesforce com o ERP não é apenas que "funciona hoje", mas que se pode explicar em cinco minutos por que cada padrão foi escolhido e quem é responsável por corrigi-lo quando algo dá errado. Uma solução que exige uma longa investigação para cada falha cria um custo operacional oculto que aumenta com o tempo.

Quando falta capacidade interna para planejar ou implementar tal conexão, o serviço de arquitetura de CRM é o caminho prático a seguir.

Recursos 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