Flow Approval Processes: eventos de mudança de registro ganham canal próprio

O que é

Até agora, processos de aprovação de fluxo em execução (running flow approval processes) escutavam um único canal de platform event que continha tanto eventos de mudança de registro (record-change events) quanto eventos de conclusão de etapa (step-completion events). Isso significa que as duas naturezas de evento competiam pela mesma fila.

O problema aparecia em operações de dados em massa. Quando uma bulk operation disparava milhares de eventos de mudança de registro, os eventos de conclusão de etapa gerados depois dessa carga entravam na fila atrás de todo esse volume. Como a fila era compartilhada, isso atrasava a conclusão de work items de aprovação e travava o progresso dos processos em execução.

Com essa mudança, eventos de mudança de registro passam a ser roteados para um canal dedicado, separado do canal de conclusão de etapa. A mudança é automática e não exige nenhuma configuração.

Por que importa

Esse é um daqueles bugs de arquitetura que só aparece em escala e que é praticamente impossível de reproduzir num ambiente de dev com poucos registros. Já vi isso acontecer num projeto onde uma integração noturna atualizava milhares de registros e, na manhã seguinte, o time de aprovadores reclamava de work items que sumiam da fila por horas. Se você tem processos de aprovação de fluxo rodando em paralelo com integrações ou jobs de carga em massa, seja via Data Loader, Bulk API ou uma integração que atualiza milhares de registros de uma vez, o comportamento anterior podia gerar sintomas confusos: aprovações represadas sem motivo aparente, aprovadores achando que o processo travou quando na verdade só estava na fila errada.

Nível de aplicação: Baixo

Mudança de infraestrutura automática do lado da Salesforce, sem nenhuma ação de configuração exigida da minha org.

Considerações de arquiteto

• Vou validar se os SLAs de aprovação que pareciam inconsistentes durante cargas em massa eram na verdade sintoma desse gargalo de fila compartilhada.
• Preciso mapear quais fluxos de aprovação da minha org rodam em paralelo com integrações ou jobs via Bulk API para monitorar a melhora de performance após o rollout.
• Vale documentar o comportamento anterior como referência histórica, caso eu precise justificar internamente por que aprovações travavam durante importações grandes.
• Não preciso abrir nenhum ticket de configuração, mas devo comunicar a melhoria para o time de operações que lida com cargas em massa recorrentes.

Pegadinhas:

• Como é uma mudança automática de plataforma, não há como testá-la isoladamente antes do rollout na minha org, então o comportamento só será validado em produção.