Flow Orchestration é poderoso para processos com paradas humanas e múltiplos atores. Para automações simples, virou bala de canhão.
Toda vez que a Salesforce entrega uma capability nova de automação, parte da comunidade tenta usá-la em todos os lugares. Aconteceu com Process Builder, com Record-Triggered Flows, e está acontecendo com Flow Orchestration.
Aqui está o critério que uso na prática para decidir se um processo merece ou não Orchestration.
Quando faz sentido
- O processo tem paradas humanas reais (aprovações, validações, formulários).
- Existem múltiplos atores participando em momentos diferentes.
- Há estados intermediários que precisam ser visíveis e auditáveis.
- O processo dura mais do que uma transação técnica.
Quando não faz sentido
- Automação puramente sistêmica (de máquina para máquina).
- Processo curto, sem espera humana.
- Quando um Record-Triggered Flow simples resolveria com menos peças.
- Quando o time ainda não está confortável com Flow básico.
A regra mental
Se você consegue desenhar o processo no quadro como uma linha reta de máquina, é Flow normal. Se você precisa desenhar caixinhas com pessoas dentro delas e setas entre elas, talvez seja Orchestration.
Usar Orchestration onde não precisa adiciona complexidade que ninguém vai querer manter. Usar Flow simples onde precisava de Orchestration empurra a complexidade pra dentro do código e da operação.
Para admins e devs: critério prático para escolher a ferramenta certa em vez de sempre ir pelo mais novo.
Automação boa não é a que parece mais complexa. É a que resolve melhor, quebra menos e alguém consegue manter depois. Vale para Orchestration também.