Steps em background agora rodam síncronos no Flow Orchestration
Atualizar a API version da orquestração para 68.0+ elimina latência desnecessária em steps que chamam ações síncronas.
Eu explico o que muda no comportamento de background steps do Flow Orchestration quando a ação chamada já é síncrona. Também mostro por que essa mudança exige uma ação explícita sua em orquestrações existentes.
O que é
Até agora, qualquer background step que contivesse um elemento Action rodava de forma assíncrona no Flow Orchestration, independentemente de a ação em si ser síncrona ou não. Isso significa que mesmo ações rápidas, que poderiam ser resolvidas na hora, entravam numa fila e adicionavam latência ao runtime da orquestração.
Com a mudança, quando a ação suporta execução síncrona, o background step que a chama passa a rodar de forma síncrona também. O resultado direto é redução da latência ponta a ponta nas execuções da orquestração, já que o step não precisa mais esperar o ciclo assíncrono para ser processado.
Esse comportamento não é automático para orquestrações já existentes. O texto oficial é claro: para aproveitar essa mudança, você precisa atualizar a API version da orquestração para 68.0 ou superior. Orquestrações que permanecerem em versões anteriores continuam com o comportamento antigo, executando todo background step com Action de forma assíncrona.
Por que importa
Na prática, isso ataca um problema que eu já vi de perto em projeto: orquestrações com múltiplos background steps que, individualmente, são rápidos, mas que somados geram um runtime arrastado por causa do overhead assíncrono. Se boa parte das suas ações já é síncrona por natureza (validações simples, cálculos, chamadas a Apex sem callout, por exemplo), você estava pagando um pedágio de latência sem necessidade.
O ponto de atenção arquitetural aqui é que essa não é uma melhoria automática. Ela exige que você revise a org e decida conscientemente quando vale a pena migrar cada orquestração para a nova API version.
Nível de aplicação: Médio
Não exige código, mas depende de atualizar API version e revalidar comportamento de cada background step existente na orquestração.
Considerações de arquiteto
- Antes de subir a API version para 68.0 ou superior, mapeie quais background steps chamam ações que suportam execução síncrona, pois só essas terão o ganho de latência.
- Avalie o impacto em orquestrações que dependem do comportamento assíncrono atual para efeitos colaterais como desacoplamento de transação ou processamento em fila, já que a mudança pode alterar timing de execução.
- Trate a atualização de API version como uma mudança de comportamento, não apenas um bump de versão, e teste em sandbox as orquestrações críticas antes de promover para produção.
- Documente na sua org quais orquestrações foram atualizadas e quais permanecem na versão antiga, para evitar inconsistência de comportamento entre fluxos similares.
Pegadinhas:
- A mudança não é retroativa, orquestrações em API version anterior a 68.0 continuam rodando todo background step com Action de forma assíncrona mesmo depois do release.