Por que a Dívida Técnica em Automações Difere da Dívida Técnica Regular
No Salesforce, é mais fácil acumular dívida técnica do que em um ambiente de desenvolvimento tradicional, pois a ferramenta permite que qualquer pessoa adicione automação sem passar por um processo formal de código.
Cada Admin que adiciona um Flow Before Save para resolver um problema pontual, cada Trigger que alguém adicionou há dois anos e ninguém se lembra o porquê, e cada campo de fórmula que contém uma dependência de um campo que não existe mais — tudo isso se acumula em uma camada que ninguém vê em sua totalidade.
A diferença fundamental entre a dívida técnica regular e a dívida técnica em automações Salesforce é que esta última quase sempre carece de documentação centralizada. O código reside em um Repository com histórico de Commits; um Flow reside em Setup sem explicação de por que foi criado. Isso torna a fase de identificação particularmente difícil — não porque o problema seja tecnicamente complexo, mas porque não há a quem perguntar.
Este artigo trata da identificação, medição e redução dessa dívida. Ele não discute a questão de quando escolher Flow e quando Apex inicialmente — para isso, há um artigo dedicado: Flow vs. Apex: Como Escolher.
Três Tipos de Dívida que se Comportam Diferentemente
Nem toda dívida técnica é igual, e o tratamento abrangente de todas como o mesmo problema leva ao desperdício de esforço. É aconselhável separar em três categorias:
| Tipo de Dívida | Exemplo Típico | O que acontece se ignorada | Prioridade de Tratamento |
|---|---|---|---|
| Dívida Estrutural | Vários Triggers no mesmo objeto sem um Framework unificador | Ordem de execução imprevisível, falha silenciosa | Alta |
| Dívida Lógica | Flow com dezenas de ramificações de decisão que representam uma regra de negócio já alterada | Decisões errôneas executadas silenciosamente | Alta |
| Dívida de Manutenção | Campos, Flows e variáveis permanentes sem documentação ou uso | Tempo de desenvolvimento prolongado, medo de tocar | Média |
A dívida estrutural e a dívida lógica geram risco operacional real — elas podem causar dados incorretos que chegam ao cliente ou a um relatório financeiro. A dívida de manutenção retarda a equipe, mas não necessariamente quebra um processo. Esta divisão determina a ordem de tratamento: primeiro, remove-se o risco operacional, depois melhora-se a velocidade de desenvolvimento.
Como Identificar a Dívida Antes que Exploda em Produção
A identificação não deve começar com uma revisão manual e abrangente de código — isso é muito caro e insustentável. Ela começa com alguns indicadores quantitativos que podem ser extraídos em uma hora:
- Número de Flows ativos em cada objeto principal (Lead, Opportunity, Case, etc.). Acima de cinco ou seis Flows ativos no mesmo objeto, a ordem de execução torna-se difícil de prever.
- Número de Triggers que não estão unificados sob um único Framework para cada objeto. Mais de um Trigger por objeto já é um sinal de alerta, a menos que exista uma camada de roteamento explícita.
- Densidade de consultas SOQL dentro de loops que aparece nos logs como Governor Limit próximo ao limite, mesmo que não tenha sido efetivamente cruzado.
- Tempo de execução incomum de Flow ou Apex Batch que aumenta ao longo do tempo sem que o volume de negócios cresça na mesma proporção.
- Campos e variáveis sem uso identificado no relatório Field Usage, que permanecem "apenas no caso de alguém precisar".
Esses indicadores não provam um problema inequívoco, mas fornecem uma lista focada de suspeitos. A combinação deles com uma compreensão profunda das integrações das quais a automação depende é detalhada em Padrões de Integração Salesforce.
Decision Framework: O que Tratar Primeiro
Nem todo achado na lista de suspeitos merece o mesmo investimento. Um Framework simples para priorização baseado em dois eixos — impacto de negócio e probabilidade de falha:
| Situação | Impacto de Negócio em caso de falha | Probabilidade de Falha a Curto Prazo | Ação |
|---|---|---|---|
| Automação em processo de pedido/faturamento com múltiplos Triggers não documentados | Alta | Alta | Refactor imediato, fora da fila normal |
| Flow complexo em atualização de status interno sem impacto externo | Baixa | Alta | Documentação e simplificação em ritmo normal |
| Trigger antigo que funciona de forma estável, mas não está claro por que existe | Potencialmente alta | Baixa | Documentação primeiro, sem intervenção imediata |
| Campos não utilizados e variáveis permanentes órfãs | Baixa | Baixa | Limpeza cíclica no nível do Release |
A regra orientadora: não se trata o que mais incomoda os desenvolvedores, mas sim o que é mais perigoso para o negócio. Um Trigger antigo e estável que ninguém entende é, muitas vezes, o caso mais tentador para se mexer primeiro — e é exatamente o caso em que uma intervenção descuidada causa o maior dano.
Cenário Organizacional: Uma Seguradora com 14 Flows na Opportunity
Suponha uma seguradora de médio porte que gerencia vendas B2B através do Salesforce há seis anos. Ao longo do tempo, acumularam-se 14 Flows ativos no objeto Opportunity: sete tratam de atualizações de estágio, três enviam notificações internas, dois sincronizam dados com uma ferramenta de BI externa, e outros dois são resquícios de um processo antigo que foi substituído há dois anos, mas nunca desativado.
O gatilho para identificar o problema foi uma falha concreta: uma transação passou para o estágio "Fechado-Ganho", mas a notificação para a equipe de subscrição não foi enviada, porque um outro Flow atualizou o mesmo campo em paralelo e criou uma sequência de execução não prevista. A equipe passou dois dias tentando entender o porquê — não porque o bug fosse complexo, mas porque ninguém sabia a ordem de execução completa dos 14 componentes.
O tratamento não foi "reescrever tudo em Apex". A equipe primeiro mapeou todos os 14 Flows e os classificou de acordo com a tabela acima: os dois Flows antigos foram desativados após verificar que não havia dependência ativa, as três notificações foram unificadas em um único Flow com lógica de roteamento clara, e as sete atualizações de estágio foram unificadas sob um único Record-Triggered Flow com ordem de execução explícita. Resultado: de 14 componentes para 6, com documentação da ordem de execução que qualquer novo desenvolvedor pode ler em quinze minutos.
Riscos no Processo de Redução em si
A redução da dívida técnica é uma operação com riscos próprios, não apenas uma correção de um risco existente:
| Risco | Como se manifesta na prática | Ação de Prevenção |
|---|---|---|
| Mudança na ordem de execução que quebra uma dependência oculta | Processo que funcionava para de funcionar após a unificação de Flows | Mapeamento completo de dependências e teste de Regressão antes de qualquer unificação |
| Exclusão de um componente "morto" que na verdade ainda é executado em um cenário raro | Falha que aparece apenas no final do trimestre ou em um cenário sazonal de ponta | Verificação de logs de execução durante um ano completo, não apenas o último mês |
| Conversão para Apex sem um proprietário de processo que entenda a regra de negócio | O novo código é "tecnicamente correto", mas implementa uma regra antiga que já foi alterada | Verificação da regra de negócio com o proprietário do processo antes de escrever o código, não apenas com o código existente |
| Refactor feito em uma única Sandbox e não sincronizado | O problema retorna no ambiente de produção após o próximo Deploy | Gerenciar a mudança através de um processo de Release regular e não como uma correção "fora da fila" |
O risco comum a todos é o mesmo fenômeno: a equipe acredita que está "apenas limpando" e, portanto, pula os testes que faria para um novo recurso. No nível de Governance, um Refactor deve passar pelo mesmo processo de aceitação que um desenvolvimento regular — não menos.
Métricas para Monitoramento Contínuo da Redução
Para saber se o esforço está realmente reduzindo a dívida e não apenas a deslocando, é aconselhável monitorar:
- Número de componentes de automação ativos por objeto, como uma métrica de tendência trimestral e não pontual.
- Tempo médio para diagnóstico de falha de automação, desde o momento do relatório até a identificação do componente responsável.
- Porcentagem de componentes documentados do total de automações ativas no cluster principal.
- Número de falhas recorrentes no mesmo componente em um período de três meses.
Organizações que têm dificuldade em priorizar entre Refactor e desenvolvimento contínuo utilizam o serviço de arquitetura de CRM para construir um plano de trabalho vinculante e mensurável.
Checklist Operacional Antes de Iniciar um Refactor
- ☐ Existe um mapa completo de todas as automações ativas no objeto relevante.
- ☐ A ordem de execução real é conhecida, não apenas pela ordem de criação.
- ☐ Cada componente destinado à remoção foi verificado em relação aos logs de execução de um ano completo.
- ☐ O proprietário do processo de negócio aprovou a regra que está sendo reimplementada.
- ☐ Existe um ambiente de teste que simula volumes de dados reais.
- ☐ Uma métrica "antes e depois" foi definida para o número de componentes e o tempo de diagnóstico.
- ☐ O processo de Refactor segue um Release normal, não um Deploy excepcional.
- ☐ Capacidade fixa foi alocada em cada Sprint para tratamento contínuo, não apenas um evento único.
Conclusão
A dívida técnica em automações Salesforce é construída silenciosamente, um componente por vez, e, portanto, também deve ser desmantelada silenciosamente — não em um grande projeto de limpeza que paralisa o desenvolvimento por um mês. As ferramentas necessárias são relativamente simples: contagem de componentes por objeto, mapeamento da ordem de execução e classificação por impacto de negócio versus probabilidade de falha. O que determina o sucesso é a continuidade — a alocação de capacidade fixa para a redução da dívida ao lado do desenvolvimento contínuo, e não a perseguição pontual do componente que causou a última falha. Uma organização que adota tal hábito de medição atinge um estado em que qualquer novo desenvolvedor pode entender em uma hora o que acontece ao salvar um registro — e isso, no final das contas, é a definição mais prática de ausência de dívida técnica.