Background Steps síncronos em Flow Approval Processes: o que muda na Winter '27

O que é

Até a Winter '27, qualquer background step que contivesse um elemento Action rodava de forma assíncrona, independentemente de a ação chamada ser síncrona ou não. Isso significava que mesmo ações rápidas e síncronas ficavam sujeitas ao overhead de processamento assíncrono dentro de um flow approval process.

Com essa mudança, background steps que chamam ações síncronas agora executam de forma síncrona, reduzindo a latência ponta a ponta do processo de aprovação em execução. O comportamento passa a respeitar a natureza da ação chamada, em vez de forçar todo background step para o modelo assíncrono.

Para aproveitar essa mudança em flow approval processes já existentes, é necessário atualizar a API version do flow approval process para 68.0 ou superior. Sem essa atualização, o comportamento anterior se mantém.

Por que importa

Esse tipo de ajuste é discreto nas release notes, mas tem impacto direto em quem já reclamou de aprovações que demoram mais do que deveriam para avançar de etapa. Background steps com Action elements são comuns em flow approval processes que disparam integrações, atualizações de registro ou chamadas a Apex, e o custo assíncrono acumulado em processos com múltiplas etapas de aprovação é real, principalmente em fluxos com SLA apertado. Já vi aprovação simples travar minutos numa etapa só porque o background step insistia em rodar assíncrono mesmo chamando uma ação trivial.

Como arquiteto, vejo isso como um ajuste de plataforma que corrige uma ineficiência estrutural, não uma nova funcionalidade que exige redesenho. O ponto de atenção é que a mudança não é automática para quem já tem flow approval processes em produção. Ela exige uma ação explícita de versionamento, o que significa que times que não revisam a API version dos seus flows periodicamente vão continuar com o comportamento antigo sem perceber.

Como se preparar

• Levante todos os flow approval processes em produção que contêm background steps com Action elements e verifique a API version atual de cada um.
• Atualize a API version para 68.0 ou superior nos processos elegíveis, testando em sandbox antes de promover para produção.
• Priorize essa atualização em flow approval processes com múltiplas etapas de aprovação ou com ações que chamam integrações externas, onde o ganho de latência é mais perceptível.
• Documente a mudança de API version como parte da rotina de manutenção de flows, já que atualizações desse tipo tendem a passar despercebidas em processos já estabilizados.

Nível de aplicação: Médio

A mudança em si é transparente, mas exige levantamento manual de flow approval processes em produção e atualização controlada de API version, o que gera trabalho operacional não trivial em orgs com muitos fluxos.

Considerações de arquiteto

• Fazer um inventário completo dos flow approval processes ativos que usam background steps com Action elements antes de qualquer atualização de API version.
• Testar em sandbox o comportamento síncrono após o bump para API 68.0, validando especialmente flow approval processes com integrações externas que podem ter side effects sensíveis a timing.
• Avaliar se ações chamadas nesses background steps são realmente síncronas, já que o ganho de latência só se materializa nesse cenário específico.
• Incluir a revisão de API version dos flow approval processes como item recorrente na governança de automação da org, evitando que esse tipo de ajuste fique perdido em processos já estabilizados.

Pegadinhas:

• A atualização não é retroativa nem automática, então flow approval processes existentes continuam no comportamento assíncrono antigo até alguém explicitamente subir a API version para 68.0 ou superior.

Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.