Flow
Automatização declarativa com estrutura clara, nomes consistentes e documentação.
Desenvolvimento e Automação
Flow ou Apex — Uma decisão informada, não um hábito.
Criação de automatizações e desenvolvimentos no Salesforce com uma escolha consciente entre declarativo e código, de acordo com a complexidade, desempenho e custo de manutenção — incluindo testes, controlo de versões e redução da dívida técnica.
Mapa de Capacidades
O que está incluído e em que ordem
O mapa mostra as camadas de trabalho neste serviço, desde a infraestrutura até às capacidades que os utilizadores visualizam.
Desenvolvimento e Automatização — Capability Map
Flow
Automatização declarativa com estrutura clara, nomes consistentes e documentação.
Apex
Lógica complexa, volumes elevados e testes unitários reais.
LWC
Interfaces dedicadas que encurtam o trabalho diário.
Platform Events
Separação de sistemas através de eventos em vez de chamadas diretas.
Testes e Qualidade
Cobertura de testes significativa e não formal, e revisão de código.
Controlo de versões
Sandboxes, lançamento controlado e documentação de alterações.
O Contexto
O que realmente é determinante aqui
A maior parte da dívida técnica no Salesforce não resulta de código deficiente, mas sim da multiplicidade de automatizações construídas separadamente no mesmo objeto, sem ninguém a ver o cenário completo.
A regra prática é simples: o que pode ser resolvido de forma declarativa e clara — deve ser construído assim. O que exige lógica complexa, alto volume ou controlo preciso da ordem das operações — justifica-se em código, com testes.
Toda a automatização precisa de um proprietário e de documentação. Uma automatização cuja razão de construção ninguém conhece permanecerá no sistema por anos e silenciosamente causará problemas.
Áreas de atuação
O que fazemos na prática
Apex
Lógica complexa, volumes elevados e testes unitários reais.
LWC
Interfaces dedicadas que encurtam o trabalho diário.
Platform Events
Separação de sistemas através de eventos em vez de chamadas diretas.
Testes e Qualidade
Cobertura de testes significativa e não formal, e revisão de código.
Controlo de versões
Sandboxes, lançamento controlado e documentação de alterações.
Matriz de decisão
As decisões que determinam o resultado
| Requisito | Declarativo | Código | O que é decisivo |
|---|---|---|---|
| Atualização de campos e condições | Flow | — | Simplicidade e manutenção |
| Lógica com muitas exceções | Difícil de manter | Apex | Número de condições e chamadas |
| Alto volume de registos | Pode encontrar limites | Apex otimizado | Âmbito do processamento |
| Interface dedicada | Página padrão | LWC | Complexidade da interação |
| Publicação para vários sistemas | Chamadas diretas | Platform Events | Número de consumidores e tolerância a falhas |
Atualização de campos e condições
- Declarativo
- Flow
- Código
- —
- O que é decisivo
- Simplicidade e manutenção
Lógica com muitas exceções
- Declarativo
- Difícil de manter
- Código
- Apex
- O que é decisivo
- Número de condições e chamadas
Alto volume de registos
- Declarativo
- Pode encontrar limites
- Código
- Apex otimizado
- O que é decisivo
- Âmbito do processamento
Interface dedicada
- Declarativo
- Página padrão
- Código
- LWC
- O que é decisivo
- Complexidade da interação
Publicação para vários sistemas
- Declarativo
- Chamadas diretas
- Código
- Platform Events
- O que é decisivo
- Número de consumidores e tolerância a falhas
Metodologia de trabalho
Fases de execução
- 01
Mapeamento de automatizações existentes
O que é executado em cada objeto e em que ordem.
- 02
Decisão da abordagem
Declarativo ou código, com justificativa documentada.
- 03
Construção
Padrão de nomenclatura, modularidade e prevenção de duplicação.
- 04
29. Testes
Cenários positivos e negativos, não apenas cobertura.
- 05
Lançamento
Sandbox, revisão e janela de lançamento definida.
- 06
Limpeza
Remoção de automatizações desnecessárias e redução de dívidas.
Continuar a partir daqui
Serviços e guias relacionados
27. Perguntas frequentes
Perguntas Frequentes
Flow é sempre preferível a Apex?
Não. Flow é preferível quando a lógica é simples e clara, pois é mais barato de manter e acessível também a Administradores. Quando há lógica complexa, grandes volumes de dados ou necessidade de controlo preciso na ordem das operações, Apex com testes é a escolha mais segura.
Quantas automações são permitidas num único objeto?
O número é menos importante que a transparência. O problema começa quando ninguém sabe o que está a ser executado e em que ordem. Um padrão organizado e a documentação são mais importantes do que uma regra rígida.
O que é considerado dívida técnica neste contexto?
Automações duplicadas, código sem testes, campos não utilizados, permissões excessivamente amplas e lógica sem um responsável. Tudo isto aumenta o risco em qualquer alteração futura.
É necessária uma ferramenta DevOps?
Quando há mais de um programador ou um ritmo de lançamento constante — sim. Num ambiente pequeno, um processo de Sandbox organizado e documentação podem ser suficientes numa fase inicial.
O próximo passo
Análise da camada de automatização
Mapearemos o que está a ser executado atualmente, identificaremos duplicações e definiremos um padrão que possa ser mantido.