Request Approvals com até 10 processos de aprovação de fluxo por autolaunched flow

O que é

O Request Approvals é o componente que permite iniciar um processo de aprovação de fluxo diretamente de uma página de registro, sem depender de botões customizados ou automações escondidas. Na Winter '27, esse componente passa a suportar até 10 processos de aprovação de fluxo autolaunched associados ao mesmo registro, e o submissor escolhe qual deles quer disparar no momento da submissão.

Antes, o componente ficava limitado a um único fluxo de aprovação por configuração. Já vi isso travar projeto inteiro quando o negócio pedia mais de um caminho de aprovação para o mesmo objeto. Agora, quando existem múltiplos autolaunched flows de aprovação relevantes para aquele objeto, todos ficam disponíveis como opções para quem está submetendo o registro para aprovação.

O texto oficial confirma que o componente funciona tanto no Lightning App Builder quanto no Experience Builder, o que significa que essa flexibilidade de múltiplos processos também chega para portais e sites de Experience Cloud, não só para páginas internas Lightning.

Por que importa

Na prática, times de negócio raramente têm um único caminho de aprovação para um objeto. Um pedido de desconto pode seguir por um processo simples quando o valor é baixo, e por outro mais complexo quando envolve múltiplos aprovadores ou exceções. Antes dessa mudança, resolver isso na interface exigia lógica condicional externa ao componente, ou múltiplos componentes na mesma página, o que gerava confusão para o usuário final e mais manutenção para quem constrói.

Com até 10 opções disponíveis diretamente no componente, dá para modelar cenários de negócio mais realistas sem sair da experiência nativa do Request Approvals. Isso reduz a necessidade de flows de invocação intermediários só para decidir qual processo de aprovação de fluxo disparar, e centraliza essa decisão na mão de quem está mais perto do contexto, o próprio submissor.

Como se preparar

• Mapeie os autolaunched flows de aprovação já existentes para os objetos onde você usa Request Approvals e identifique quais fazem sentido aparecer juntos na mesma tela.
• Revise a nomenclatura desses flows, já que o submissor vai precisar diferenciar as opções com base em nomes claros no momento da escolha.
• Se você já compensava a ausência dessa funcionalidade com múltiplos componentes ou lógica condicional em Apex ou flow adicional, avalie simplificar essa camada agora que o componente nativo suporta múltiplas opções.
• Teste o comportamento tanto em páginas internas do Lightning App Builder quanto em páginas de Experience Builder, já que o release note trata os dois cenários como suportados igualmente.

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

A configuração em si é simples via componente, mas exige repensar a arquitetura de aprovação existente e migrar lógica condicional que antes ficava fora do componente.

Considerações de arquiteto

• Mapeie antes da ativação quantos autolaunched flows de aprovação já existem por objeto para não ultrapassar o limite de 10 e evitar poluir a tela do submissor com opções redundantes.
• Reavalie flows de invocação intermediários que hoje decidem qual processo disparar, já que essa lógica pode ser aposentada e substituída pela escolha nativa do usuário.
• Padronize a nomenclatura dos autolaunched flows de aprovação com labels de negócio claros, pois o submissor vai decidir com base nesse nome, não na lógica interna do flow.
• Valide o comportamento em Experience Builder separadamente do Lightning App Builder, principalmente permissões de execução dos flows para usuários de portal ou site externo.

Pegadinhas:

• Usuários de Experience Cloud precisam ter acesso de execução aos autolaunched flows expostos, senão a opção aparece mas falha na submissão.

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