Orchestration Runs: eventos de mudança de registro ganham canal próprio

O que é

As release notes da Winter '27 trazem uma mudança de infraestrutura no Flow Orchestration: as execuções de orquestração (orchestration runs) agora roteiam eventos de mudança de registro (record-change events) para um canal dedicado, separado do canal de eventos de conclusão de etapa (step-completion events).

Antes, orchestration runs escutavam um único canal de platform events que misturava os dois tipos de evento. O problema aparecia em operações de dados em massa: quando uma atualização bulk disparava milhares de record-change events, os step-completion events de etapas concluídas depois dessa atualização ficavam enfileirados atrás deles. Como a fila era compartilhada, isso travava a conclusão de alguns work items e atrasava o progresso da orquestração como um todo.

A mudança é automática e não requer nenhuma configuração adicional. Não há setting, permission ou API version associada a habilitar esse comportamento, ele já vem assim na Winter '27.

Por que importa

Esse é o tipo de correção que não aparece em nenhuma demo, mas que separa uma orquestração confiável de uma que trava silenciosamente sob carga. Eu já revisei org onde essa fila compartilhada era exatamente o motivo de work items completados sumirem da tela por minutos, até o time de suporte abrir chamado achando que era bug. Se você já implementou Flow Orchestration em processos que convivem com integrações ou cargas de dados em lote, provavelmente já viu step-completion events represados atrás de uma enxurrada de record-change events gerada por uma atualização bulk em paralelo. O usuário completa o work item, mas a orquestração demora para reconhecer isso e avançar.

Como arquiteto, eu vejo essa separação de canais como uma correção estrutural, não um recurso novo para vender ao negócio. Ela reduz contenção em cenários que antes exigiam workaround (como espaçar cargas bulk fora do horário de uso das orquestrações). Isso é especialmente relevante para quem tem orquestrações rodando em paralelo com integrações via Bulk API ou processos de migração que geram volume alto de DML.

Como se preparar

• Não há ação de configuração necessária, a mudança é automática no roteamento interno de platform events.
• Se você tinha workarounds operacionais para evitar rodar orquestrações durante janelas de carga bulk, vale reavaliar se ainda são necessários.
• Monitore orquestrações que historicamente apresentavam atraso na conclusão de work items durante ou logo após operações de dados em massa, e valide se o comportamento melhorou.
• Documente esse ganho de resiliência para times de dados que compartilham a org com processos de orquestração, é um argumento a favor de rodar cargas bulk sem coordenação manual prévia.

Nível de aplicação: Baixo

É uma mudança de infraestrutura automática no roteamento de platform events, sem nenhuma configuração, permission ou ação obrigatória do arquiteto.

Considerações de arquiteto

• Vale mapear quais orquestrações da sua org convivem com cargas Bulk API ou migrações de alto volume para identificar candidatas naturais a essa melhoria.
• Reavalie workarounds operacionais existentes, como janelas de horário reservadas para cargas bulk fora do uso das orquestrações, pois podem deixar de ser necessários.
• Estabeleça uma linha de base de tempo de conclusão de work items antes e depois da Winter '27 para comprovar objetivamente o ganho de performance.
• Comunique times de dados e integração sobre essa mudança, já que ela remove um argumento técnico contra rodar cargas bulk sem coordenação prévia com o time de automação.

Pegadinhas:

• Como não há setting nem API version associada, não existe forma de forçar ou verificar explicitamente se o comportamento antigo ainda está ativo em algum cenário específico.

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