.svg)
A própria Salesforce reconhece em sua documentação oficial que regras de negócio críticas podem precisar de uma fonte de verdade externa. A comunidade técnica e os MVPs do ecossistema estão falando do mesmo tema em 2026. Veja o que está em jogo quando uma operação enterprise coloca toda a sua lógica de aceitação, precificação e elegibilidade dentro do Salesforce, e quando vale a pena separar.
Tecnologia
Nos últimos meses, três operações enterprise brasileiras nos procuraram com versões diferentes da mesma história. Setores diferentes, portes diferentes, equipes diferentes. O sintoma narrado era idêntico: o Salesforce, que entrou na empresa há cinco, sete, dez anos para resolver gestão de pipeline e atendimento ao cliente, virou também o lugar onde mora a lógica crítica do negócio. Aprovação de risco. Regras de aceitação. Lógica de precificação. Cálculo de comissão. Tudo dentro de Flows, Apex e validation rules, espalhado em camadas que foram crescendo organicamente.
E em todas as três conversas, em algum momento, a mesma frase apareceu, dita pelo CTO ou pelo Diretor de Tecnologia: "o time de negócio não consegue mais mexer no que importa".
Esse artigo não é sobre sair do Salesforce. Salesforce é uma das melhores plataformas de CRM do mundo, e nenhuma operação séria deveria desmontar uma implementação madura. O artigo é sobre uma separação que o próprio ecossistema Salesforce começou a discutir abertamente em 2026: a separação entre CRM e motor de regras de negócio.
São coisas diferentes. Vamos olhar por quê.
Antes de qualquer outra coisa, vale dimensionar o que está sendo discutido. Salesforce roda em 150 mil empresas no mundo, é líder absoluto em participação de mercado de CRM há mais de uma década, e tem mais de 25 anos de evolução de produto. No Brasil, é a base de operações de seguradoras como Sompo, SulAmérica e dezenas de outras empresas enterprise dos setores financeiro, varejo, saúde e indústria.
A força do Salesforce é, e continua sendo, gestão do relacionamento com o cliente. Pipeline comercial, gestão de leads, omnichannel de atendimento, dados unificados do cliente em todos os pontos de contato. Para essas funções, é uma das ferramentas mais sofisticadas que existem.
O ponto deste artigo começa quando a operação, naturalmente, passa a usar Salesforce para coisas que não são exatamente gestão de relacionamento, são decisões de negócio. E aí o ecossistema Salesforce tem limites que a própria comunidade técnica vem mapeando com cada vez mais clareza.
Dois movimentos da Salesforce nos últimos anos transformaram o Flow no caminho padrão para automatizar qualquer coisa na plataforma. Em 2022, a empresa anunciou a aposentadoria do Workflow Rules e do Process Builder, deixando o Flow como única ferramenta declarativa de automação. A partir daí, todo time de admin passou a construir Flow para tudo: atualização de campo, escalonamento de caso, validação, regra de negócio. Tudo Flow.
E em 2026, a chegada do Agentforce Vibes e ferramentas similares de geração de Flow via linguagem natural acelerou ainda mais essa criação. Hoje qualquer pessoa, com qualquer nível técnico, consegue gerar um Flow descrevendo em português o que quer que aconteça.
O resultado é o que a consultoria americana Digital Mass chamou, em artigo de março de 2026, de "the automation graveyard nobody wants to audit", o cemitério de automações que ninguém quer auditar. A descrição da Digital Mass merece ser citada quase na íntegra, porque captura com precisão o que vimos nas três operações brasileiras:
"Abra Setup. Navegue até Flows. Conte quantos tem. Agora se pergunte: quantos estão ativos? Quantos disparam no mesmo objeto? Quantos foram construídos por alguém que saiu da empresa dois anos atrás? Quantos têm nome tipo 'Lead Assignment v3 FINAL (use esse)'? Se suas respostas são 'demais', 'provavelmente vários', 'pelo menos alguns' e 'não me julgue', você não está sozinho."
Um MVP da Salesforce citado no mesmo artigo resume o que está acontecendo de forma direta: "se você consegue construir as coisas mais rápido, isso não significa que vai construir coisas melhores mais rápido. Significa que vai fazer mais, mais rápido."
A documentação oficial da Salesforce (Apex Developer Guide e Flow Limits and Considerations) lista os governor limits que toda transação síncrona precisa respeitar. Os mais importantes para entender o problema:
Esses limites existem porque o Salesforce é multitenant. Sua transação compartilha recursos com milhares de outras organizações na mesma infraestrutura. Os limites protegem o ambiente coletivo.
O problema começa quando regras de negócio críticas, que precisam ler dados de múltiplos objetos, calcular elegibilidade, aplicar políticas de precificação, e fazer tudo isso em volume, começam a esbarrar nesses limites. E como múltiplos Flows e Apex triggers rodam dentro da mesma transação, eles compartilham o mesmo orçamento de queries e DML. Não é orçamento por Flow. É orçamento total da transação.
O resultado prático, descrito pela Digital Mass como um dos cinco sintomas do problema, é o que mais aparece em conversas de diagnóstico: erros de governor limit aleatórios que ninguém consegue reproduzir. Os Flows funcionam 99% do tempo. Aí, aparentemente do nada, um usuário bate no limite de CPU ou de SOQL. A inconsistência é o sinal. Quer dizer que múltiplas automações estão se acumulando de formas que dependem dos dados específicos daquela transação.
Trabalhando junto com a literatura técnica do próprio ecossistema (Trailhead da Salesforce, artigos de MVPs, consultorias especializadas), os cinco sinais mais frequentes de que uma operação enterprise atingiu o limite do "tudo no Salesforce" são:
1. Múltiplas automações disparando no mesmo objeto sem ordem clara de execução. Um Workflow Rule de 2019, um Process Builder de 2020, dois Record-Triggered Flows de 2022, e um Apex trigger adicionado no último trimestre. Todos rodando em Opportunity. Todos tentando atualizar registros relacionados. Brigando entre si de formas que só aparecem quando uma combinação específica de valores aciona o conflito em produção numa terça-feira à tarde.
2. Flows com mais de 50 elementos consumindo vários segundos de CPU. A regra prática da comunidade Salesforce, citada repetidamente em fóruns técnicos: se um Flow tem mais de 50 elementos ou consome mais de três segundos de CPU, ele já passou do ponto em que Flow é a ferramenta certa. Você está empurrando a plataforma contra os seus próprios limites.
3. Sem documentação, sem convenção de nomes, sem dono claro. Se você não consegue saber o que um Flow faz só pelo nome, e o campo de descrição está vazio, e a pessoa que construiu já saiu da empresa, o que existe ali não é mais automação. É passivo operacional disfarçado de automação.
4. Subfluxos chamando subfluxos chamando subfluxos. Modularidade é boa em teoria. Na prática, cadeias profundas de subflows criam caminhos de execução praticamente impossíveis de debugar quando algo quebra. E todas compartilham governor limits com qualquer outra automação na transação.
5. Governor limit errors aleatórios e não reproduzíveis. Esse é o sinal mais claro de todos, e o mais frustrante para o time. Quando o erro depende da combinação específica de dados na transação, debug se torna investigação forense.
Se uma operação reconhece três ou mais desses sinais, o ecossistema técnico Salesforce trata como certeza que existe dívida técnica significativa em automação, custando tempo, dinheiro ou os dois.
Esse é o ponto que mais nos surpreendeu na pesquisa para este artigo. A própria Salesforce tem um produto chamado Business Rules Engine (BRE), parte do Industry Cloud, e na página oficial deles a descrição do produto inclui literalmente esta frase:
"Mantenha uma única fonte da verdade para suas regras de negócio, mesmo fora do Salesforce. Use nossas APIs para conectar sua lógica a websites externos, aplicativos móveis e portais para garantir decisões consistentes em todo lugar."
(Tradução nossa do material oficial da Salesforce em inglês.)
A própria Salesforce está reconhecendo, em material de marketing oficial, que regras de negócio podem precisar viver fora do Salesforce e ser consultadas pelos sistemas, incluindo o próprio Salesforce, via API. Isso não é argumento de vendedor de motor de regras local. É posição oficial da plataforma.
A pergunta lógica que segue é: se a Salesforce reconhece esse padrão arquitetural, por que a maioria das operações brasileiras ainda mantém tudo dentro? A resposta honesta tem duas partes.
A primeira é histórica. Quando o Salesforce entrou no Brasil, há quinze, vinte anos, a oferta de motores de regras gerenciados em português era inexistente. A escolha era código customizado dentro do Salesforce ou implantar Drools, FICO, IBM ODM, com complexidades próprias. Naquela época, manter tudo no Salesforce era a opção mais pragmática.
A segunda é cultural. Uma vez que a operação aprendeu a fazer tudo dentro do Salesforce, cada novo problema é resolvido com a ferramenta conhecida. Mais um Flow. Mais um trigger. A solução técnica seguiu a regra de Maslow: para quem tem martelo, tudo é prego.
A separação que recomendamos, e que a própria documentação da Salesforce sugere para casos de uso de regras complexas, é simples no conceito e demanda disciplina na execução.
Salesforce continua sendo o CRM. Cadastro de cliente, gestão de oportunidade, histórico de interação, omnichannel, dashboard comercial. Tudo isso fica onde está e funciona muito bem.
Um motor de regras gerenciado fica fora. Aprovação de risco, regras de aceitação, política de precificação, cálculo de comissão, lógica de elegibilidade. Tudo isso vive numa plataforma dedicada, com interface visual para o time de negócio, versionamento, simulação de impacto, audit trail completo.
A integração é feita por API. Quando o Salesforce precisa de uma decisão (um Apex call out, um Flow invocable, uma chamada de External Service), ele consulta o motor externo e recebe a decisão pronta, com o motivo, em formato estruturado.
O resultado é que o time de Salesforce volta a fazer o que faz bem: gerir relacionamento e processo comercial. E o time de negócio recupera a capacidade de mudar a política da empresa sem entrar na fila de desenvolvimento do CRM. Sem mexer em Flow, sem Apex, sem deploy.
Há um detalhe específico que tem aparecido em conversas de diagnóstico nos últimos meses, e merece atenção do CFO especificamente. A Salesforce, em sua oferta mais recente de IA agêntica (Agentforce), adotou modelo de cobrança por conversa. Cada interação do agente é uma unidade na conta.
Esse modelo segue a tendência da maioria das plataformas internacionais de motor de regras (FICO, IBM ODM, DecisionRules), que cobram por transação ou por requisição processada. Em operações que crescem em volume, o custo de licença cresce na mesma proporção do sucesso da automação.
Plataformas de motor de regras brasileiras como a Abaccus operam em modelo diferente. A cobrança é por motor de regras ativo, com mensalidade fixa. O volume de decisões processadas não influencia o preço. Para uma operação que automatiza uma regra crítica via API e a chama dez milhões de vezes por mês hoje, e cinquenta milhões no ano que vem, a conta é a mesma.
Essa diferença, em três anos de operação enterprise, costuma ser ordem de grandeza, e quase nunca entra na análise de TCO da decisão de arquitetura. Vale fazer a simulação antes de assinar qualquer coisa.
Vamos ser honestos sobre os cenários em que separar não faz sentido, porque eles existem.
Operações com poucas regras estáveis. Se a sua empresa tem vinte ou trinta regras de negócio que mudam uma vez por ano, e seu time de Salesforce dá conta dessa carga sem fricção, separar é overhead desnecessário. Mantenha tudo lá.
Empresas com baixa diferenciação por regra. Se o que diferencia sua oferta no mercado não é a complexidade ou agilidade das suas regras de negócio, e sim outras dimensões (experiência do cliente, produto, marca), o investimento em motor de regras dedicado pode estar mal alocado.
Times Salesforce muito maduros e dimensionados. Empresas que já investiram pesadamente em arquitetura de Apex, governança formal de Flows, CI/CD para a plataforma, e têm equipe técnica forte dedicada, podem continuar evoluindo o que têm. A maturidade compensa parcialmente as limitações.
Fora desses três cenários, a separação entre CRM e motor de regras costuma valer cada centavo. Não pela tecnologia. Pela autonomia que ela devolve ao time de negócio.
Depois de ter essa conversa com diretores e CTOs em três operações brasileiras nos últimos meses, a pergunta que separa as decisões claras das ambíguas é uma só:
Quem hoje, na sua operação, precisa mudar uma regra de negócio crítica, e como ela faz?
Se a resposta envolve abrir ticket para o time de Salesforce, esperar prioridade na sprint, e voltar para validar duas semanas depois, você já tem o seu diagnóstico. A regra não está onde deveria estar.
Se sua operação está nesse ponto, vale uma conversa estruturada de 45 minutos com nosso time. Podemos mapear quais regras fazem sentido sair do Salesforce primeiro, qual a arquitetura de integração mais simples para a sua realidade, e qual o impacto financeiro real em três anos. Sem compromisso, com um número concreto para levar para o Comitê.
