Integração Salesforce + ERP (TOTVS, Senior, Sankhya): como funciona na prática

O vendedor fecha a negociação no Salesforce, comemora, e em seguida abre uma planilha para redigitar o pedido no ERP. No dia seguinte, o cliente liga perguntando sobre o faturamento e ninguém do comercial sabe responder, porque essa informação mora em outro sistema. No fim do mês, o financeiro descobre que o preço usado na proposta estava desatualizado havia duas semanas. Se esse roteiro soa familiar, o problema não é o CRM nem o ERP. É o espaço vazio entre os dois.

Integrar o Salesforce ao ERP é, na maioria das empresas B2B brasileiras, o passo que transforma o CRM de “agenda de vendedor” em ferramenta de operação. Mas também é a parte do projeto que mais gera atraso, estouro de orçamento e frustração quando é tratada como detalhe técnico. Este artigo explica como essa integração funciona de verdade, o que muda entre TOTVS, Senior e Sankhya, e como planejar o projeto para ele não virar uma novela.

A integração não é um “conector”: é uma decisão sobre quem manda em cada dado

O erro mais comum é imaginar que integrar significa instalar um plugin que “liga” um sistema no outro. Na prática, antes de qualquer linha de código, a empresa precisa responder uma pergunta de negócio: qual sistema é a fonte da verdade para cada informação?

Em quase todos os cenários que atendemos, a divisão fica mais ou menos assim:

O ERP é dono do que é fiscal e financeiro. Cadastro fiscal do cliente, produtos, tabelas de preço, estoque, condições de pagamento, limite de crédito, pedido faturado, nota fiscal e títulos em aberto. Isso nasce e vive no ERP, e o Salesforce apenas consulta ou recebe uma cópia.

O Salesforce é dono do que é relacionamento e funil. Leads, oportunidades, histórico de contatos, propostas em negociação, previsão de vendas e atendimento. O ERP não precisa saber que um lead abriu três e-mails na semana passada.

Alguns dados são compartilhados e exigem regra clara. O cadastro de cliente é o exemplo clássico: o comercial cria a conta no Salesforce durante a prospecção, mas o cliente só “existe” para o ERP quando é validado (CNPJ, inscrição estadual, regime tributário). Quem pode editar o endereço depois disso? Se as duas pontas puderem, alguém vai sobrescrever alguém.

Essa definição parece burocrática, mas é ela que evita o cenário mais caro de todos: dados divergentes nos dois sistemas e ninguém sabendo qual está certo.

Os fluxos que realmente importam (e a ordem em que costumam entrar)

Uma integração Salesforce + ERP não é um bloco único. Ela é composta por fluxos independentes, cada um com sua direção, frequência e complexidade. Os mais comuns são:

Clientes e contatos. Normalmente bidirecional: o Salesforce envia o cliente novo para cadastro no ERP e recebe de volta o código interno e o status de aprovação. É o fluxo que parece mais simples e que mais esconde regras (validação de CNPJ, duplicidade, clientes com várias filiais).

Produtos e tabelas de preço. Quase sempre do ERP para o Salesforce. O vendedor precisa montar a proposta com o catálogo e o preço vigentes, sem depender de alguém exportar planilha.

Estoque e disponibilidade. Do ERP para o Salesforce, mas aqui a pergunta muda: o vendedor precisa do saldo exato no momento da venda ou uma atualização a cada hora resolve? A resposta define a arquitetura.

Pedido de venda. Do Salesforce para o ERP. Quando a oportunidade é ganha, o pedido é gerado no ERP sem redigitação. É geralmente o fluxo com maior retorno imediato e maior risco, porque envolve regras fiscais, impostos e aprovações.

Status do pedido, faturamento e financeiro. Do ERP de volta para o Salesforce: pedido faturado, nota emitida, títulos vencidos, limite de crédito disponível. É isso que permite ao vendedor e ao atendimento responderem o cliente sem abrir chamado interno.

A recomendação que fazemos quase sempre é não tentar colocar todos os fluxos no ar de uma vez. Começar por clientes, produtos e preços, validar a qualidade dos dados, e só então ativar o pedido de venda reduz drasticamente o risco. É a mesma lógica que defendemos em como priorizar melhorias no Salesforce: entregar valor em ondas, medindo cada uma, em vez de um big bang que ninguém consegue homologar.

Tempo real, assíncrono ou em lote: como a arquitetura é escolhida

A Salesforce documenta um conjunto de padrões de integração que servem de referência para qualquer projeto sério. Entre eles estão o modelo em que o Salesforce chama o sistema externo e espera a resposta, o modelo em que ele dispara a chamada e segue sem aguardar a conclusão, a sincronização periódica em lote, e o cenário em que o sistema externo é quem chama o Salesforce para criar ou atualizar registros. Traduzindo para o dia a dia de uma integração com ERP:

Consulta em tempo real (pergunta e resposta). O vendedor clica em “consultar crédito” e o Salesforce pergunta ao ERP naquele instante. Ideal para informações que mudam rápido e são críticas na decisão, como limite de crédito ou estoque de item escasso. O preço disso é a dependência: se o ERP estiver fora do ar, o botão não funciona.

Envio assíncrono (dispara e confirma depois). O pedido é enviado ao ERP, que confirma o recebimento na hora e processa em seguida, devolvendo o resultado mais tarde. É o modelo mais saudável para pedidos de venda, porque não trava o usuário e tolera lentidão do outro lado.

Sincronização em lote. De tempos em tempos, um processo atualiza produtos, preços ou títulos financeiros em volume. Funciona muito bem para dados que não precisam estar atualizados ao segundo e costuma ser o mais barato de construir e manter.

O ERP chamando o Salesforce. Quando o pedido é faturado, o próprio ERP (ou um middleware) avisa o Salesforce e atualiza o status. Evita que o CRM fique perguntando a cada minuto se algo mudou.

Existe ainda a decisão de integrar ponto a ponto ou usar um middleware (MuleSoft, ou plataformas de integração mais leves). Para uma ou duas integrações com volume moderado, ponto a ponto bem construído resolve. Quando a empresa já prevê conectar e-commerce, WMS, plataforma de WhatsApp e BI, a camada intermediária compensa, porque centraliza monitoramento, reprocessamento e regras de transformação. Esse tipo de decisão também aparece em outros contextos, como mostramos no artigo sobre WhatsApp unificado no Salesforce.

TOTVS, Senior e Sankhya: o que muda de um ERP para outro

Os três ERPs mais presentes nos projetos de médias empresas brasileiras expõem APIs REST, mas cada um tem particularidades que impactam prazo e custo. Conhecer essas diferenças antes de fechar o escopo evita surpresas.

TOTVS Protheus

O Protheus tem um servidor REST nativo, mas ele precisa ser habilitado e configurado no ambiente (no arquivo de configuração do servidor de aplicação), o que exige alguém com acesso técnico à infraestrutura do cliente. Além disso, guias de integradores do mercado lembram que o cliente precisa ter licença contratada com a TOTVS para uso das APIs, algo que muitas vezes só é descoberto no meio do projeto.

O ponto de atenção mais relevante é o grau de customização. Poucas empresas usam o Protheus “de fábrica”: campos customizados, rotinas específicas em ADVPL e pontos de entrada alteram as regras de gravação de pedidos e clientes. Na prática, é comum que parte da integração exija desenvolvimento do lado do Protheus, feito pela equipe interna ou pela consultoria TOTVS do cliente. Por isso, o projeto precisa de um responsável técnico do ERP nomeado desde o início, não “quando precisar”.

Senior X

A plataforma Senior X tem um portal de desenvolvedor com documentação das APIs e autenticação por chave e segredo, que gera os tokens usados nas demais chamadas. Um detalhe que muda o desenho da integração: segundo a própria documentação da Senior, a criação de pedido de venda no ERP Senior X é assíncrona. Uma resposta de sucesso na chamada significa que a integração foi registrada, não que o pedido já existe; o resultado da geração chega depois, via webhook.

Isso é ótimo do ponto de vista de arquitetura, porque combina exatamente com o padrão de envio assíncrono descrito acima. Mas exige que o lado Salesforce esteja preparado para receber esse retorno, tratar erros que aparecem minutos depois (um produto inativo, uma condição de pagamento inválida) e mostrar isso ao vendedor de forma compreensível. Projetos que ignoram essa etapa acabam com pedidos “enviados” que nunca foram criados.

Sankhya

A Sankhya centraliza todas as integrações em um API Gateway obrigatório, válido tanto para clientes em nuvem quanto on premise. A documentação exige uma versão mínima do Sankhya Om para usar o gateway, e a autenticação combina credenciais do integrador (client ID e secret) com um token gerado pelo próprio cliente dentro do ERP.

Há dois pontos práticos que valem destaque. Primeiro, as permissões da integração ficam amarradas a um usuário do Sankhya Om escolhido na geração do token; restringir ou liberar o que a integração pode fazer é configurar esse usuário, então vale criar um usuário técnico dedicado em vez de usar o login de alguém da equipe. Segundo, o fluxo de liberação envolve cadastro do integrador no portal de desenvolvedor da Sankhya e etapas do lado do cliente, o que precisa entrar no cronograma. A boa notícia é que o registro em ambiente de testes não gera custo para cliente nem parceiro.

Onde os projetos de integração costumam dar errado

Depois de dezenas de projetos, os problemas se repetem com uma regularidade quase previsível. Nenhum deles é exclusivamente técnico.

Dados sujos migrados como se estivessem limpos. Clientes duplicados no ERP, produtos inativos ainda visíveis, tabelas de preço paralelas. A integração não limpa nada; ela apenas espalha a sujeira para o outro sistema mais rápido. Um saneamento mínimo antes da primeira carga vale cada hora investida.

Regra de negócio que só existe na cabeça de alguém. “Pedido acima de tal valor para cliente novo vai para aprovação do diretor, menos se for cliente de tal região.” Se isso não for levantado e documentado, a integração vai funcionar tecnicamente e falhar operacionalmente. É exatamente por isso que o L.E.A.D., nossa metodologia, começa pelo Levantamento.

Ninguém do lado do ERP comprometido. A consultoria Salesforce constrói a ponta do CRM, mas precisa de acesso a ambiente de homologação, credenciais, documentação de customizações e alguém que responda dúvidas do ERP em dias, não em semanas. Quando esse papel não existe, o cronograma é refém.

Falta de monitoramento e reprocessamento. Integrações falham: o ERP sai do ar, um campo obrigatório vem vazio, um token expira. A pergunta não é “se” vai falhar, mas “quem descobre e em quanto tempo”. Um painel de logs com erros legíveis e a possibilidade de reenviar uma mensagem sem intervenção de desenvolvedor separam uma integração profissional de uma gambiarra.

Achar que o projeto termina no go-live. ERP recebe atualização, o Salesforce tem três releases por ano, a empresa cria um novo tipo de pedido. Integração é um ativo vivo, e precisa de dono depois da entrada em produção. Falamos disso em detalhe no artigo sobre quanto custa a sustentação Salesforce e na comparação entre sustentação interna e terceirizada.

Esse cenário não é exclusivo do Brasil. No relatório de conectividade de 2025 da MuleSoft, feito com 1.050 líderes de TI, 95% das organizações disseram enfrentar desafios de integração, e as equipes de TI relataram gastar cerca de 39% do tempo construindo integrações customizadas. Integração mal planejada consome exatamente o recurso mais escasso da empresa: tempo das pessoas técnicas.

Como planejar o projeto para ele caber no prazo e no orçamento

Não existe preço de tabela para integração com ERP, porque o esforço depende menos do nome do ERP e mais de algumas variáveis concretas. Na hora de dimensionar, estas são as perguntas que realmente movem o número:

Quantos fluxos e em quais direções? Cada fluxo bidirecional custa bem mais que um unidirecional, porque exige tratamento de conflito.

Quão customizado é o ERP? Um Sankhya ou Senior X próximo do padrão integra muito mais rápido que um Protheus com quinze anos de customizações.

Qual o volume e a exigência de tempo real? Mil pedidos por mês em modelo assíncrono é um projeto; dez mil consultas de estoque em tempo real por dia é outro.

Existe middleware ou será ponto a ponto? O middleware aumenta o investimento inicial e reduz o custo de evolução.

Quem faz o lado do ERP? Se a consultoria precisar desenvolver rotinas dentro do ERP, o escopo muda. Se o cliente tem time próprio, é preciso alinhar agenda desde o início.

Com essas respostas, a abordagem que mais funciona é dividir em fases: uma primeira entrega com os fluxos de cadastro (clientes, produtos, preços), uma segunda com o pedido de venda e uma terceira com o retorno de faturamento e financeiro. Cada fase tem homologação própria, e o time comercial começa a sentir o ganho semanas antes de o projeto inteiro terminar.

Perguntas frequentes

Dá para integrar Salesforce com ERP sem desenvolvimento?

Para cenários muito simples, como uma carga periódica de produtos, ferramentas de integração de baixo código podem resolver. Mas assim que entram regras fiscais, pedidos de venda e tratamento de erros, algum nível de desenvolvimento e configuração técnica é inevitável, tanto no Salesforce quanto, muitas vezes, no ERP.

Quanto tempo leva uma integração Salesforce + ERP?

Depende do número de fluxos, do grau de customização do ERP e da disponibilidade do time técnico do cliente. Uma integração faseada, começando pelos cadastros, costuma colocar as primeiras entregas em produção bem antes do projeto completo, o que reduz risco e antecipa resultado.

Preciso do MuleSoft para integrar com TOTVS, Senior ou Sankhya?

Não necessariamente. O MuleSoft faz muito sentido quando a empresa terá várias integrações e precisa de governança centralizada. Para uma única integração com volume moderado, uma solução ponto a ponto bem arquitetada, com logs e reprocessamento, costuma ser mais adequada ao orçamento.

O vendedor consegue ver estoque e crédito do cliente dentro do Salesforce?

Sim, e esse é um dos ganhos mais percebidos pelo time comercial. A decisão é se a informação será consultada em tempo real no momento da venda ou sincronizada periodicamente, o que depende de quanto ela muda e de quão crítica é para fechar o pedido.

O que acontece se o ERP ficar fora do ar?

Uma integração bem desenhada não perde dados: os pedidos ficam na fila e são reenviados quando o ERP volta, e os erros aparecem em um painel de monitoramento. Por isso a escolha por modelos assíncronos e a camada de reprocessamento são tão importantes quanto o fluxo em si.

Fontes citadas neste artigo

• Salesforce — Integration Patterns and Practices
• MuleSoft — 2025 Connectivity Benchmark Report
• Salesforce — 2025 MuleSoft Connectivity Benchmark Report Insights
• TOTVS Developers — REST no Protheus: básico do básico
• Base.com — Integração com o TOTVS Protheus: guia completo de configuração
• Senior Sistemas — ERP Senior X: integração do pedido de venda via API
• Sankhya — API de Serviços Gateway
• Sankhya — Guia de Integração com o Sankhya Om
• Sankhya — FAQ de integração