Kanban Board em Screen Flow: o que muda no Spring '26 para quem constrói telas guiadas

Como o componente se encaixa em um Screen Flow

O Spring '26 trouxe um componente nativo de Kanban Board para Screen Flows. Em vez de depender de Lightning Web Components customizados ou de soluções da AppExchange para exibir registros agrupados em colunas, agora é possível montar essa visualização direto no Flow Builder, de forma declarativa.

A mecânica é direta: o componente recebe uma coleção de sObjects, agrupa os registros em colunas com base em um campo picklist — StageName, Status, Priority, o que fizer sentido no contexto — exibe até cinco campos por card e ainda permite somatórios por coluna. Tudo dentro de uma tela de Screen Flow, sem uma linha de Apex ou JavaScript.

O fluxo básico de configuração não foge muito do que já conhecemos:

1. Um Get Records traz a coleção desejada — por exemplo, Opportunities abertas de um determinado owner ou queue — com todos os campos que serão exibidos no card.
2. Em uma tela, adiciona-se o componente Kanban Board, apontando a Source Collection para a coleção retornada.
3. Define-se o campo picklist no Group By (ex.: StageName), o estilo do header (texto simples ou path), o campo de título do card e os campos adicionais — até quatro além do título.
4. Opcionalmente, habilita-se um footer com totais ou somatórios por coluna, útil para revisões de pipeline ou checagens pré-aprovação.

Um ponto que precisa ficar claro antes de qualquer entrega: o componente é, por padrão, uma camada de visualização. Ele não persiste alterações automaticamente. Se a tela precisar capturar mudanças — um revisor movendo registros entre colunas, por exemplo —, é necessário modelar isso com Decision, Assignment e Update Records após a tela. Não existe "drag and drop persistente" mágico aqui. A lógica de gravação continua sob responsabilidade de quem está desenhando o Flow.

Onde isso aparece em projeto real

Alguns cenários onde o Kanban Board pode substituir telas customizadas ou relatórios estáticos com legitimidade:

• Revisão de pipeline em comitês comerciais, com Opportunities agrupadas por Stage e somatório de Amount por coluna.
• Triagem de Cases por Status ou Priority em rotinas de atendimento.
• Backlog de Tasks organizado por Priority antes de uma reunião de planejamento.
• Pré-aprovações onde o aprovador precisa visualizar grupos de registros e seus totais antes de avançar para o passo de approval.

Em todos esses cenários, o ganho é menos de função e mais de experiência: substituir listas longas e relatórios estáticos por uma visualização que efetivamente ajuda na tomada de decisão.

Cuidados antes de empacotar como padrão de projeto

Para quem trabalha com Flow no dia a dia, esse é o tipo de componente que reduz a justificativa para criar LWCs customizados em casos simples de visualização. Antes, qualquer demanda de "quero ver isso em colunas tipo Kanban dentro de um processo guiado" caía direto na fila de desenvolvimento. Agora, um admin consegue entregar a primeira versão sem depender de engenharia.

Dito isso, alguns pontos merecem teste em sandbox antes de qualquer compromisso com cliente:

• Volume da coleção: o Get Records precisa ser filtrado. Renderizar centenas de cards em uma tela de Flow degrada a experiência de forma perceptível. Aplique filtros por owner, data, status ativo — o que fizer sentido para o contexto.
• Quantidade de campos no card: o limite é cinco, mas o ideal costuma ser dois a quatro. Card poluído não ajuda em decisão rápida.
• Picklists com muitos valores: se o campo usado no Group By tiver dezenas de valores, a tela vira uma navegação horizontal cansativa. Em alguns casos, vale criar uma picklist auxiliar com agrupamentos mais enxutos especificamente para o uso no Kanban.
• Persistência versus leitura: deixe explícito no design do Flow se a tela é apenas leitura ou se gera escrita. Misturar os dois comportamentos sem feedback visual adequado confunde o usuário final e gera retrabalho de suporte.

Vale a atenção?

É uma adição incremental, mas com impacto real em adoção. Telas de Flow são funcionais por natureza — e essa funcionalidade sem apelo visual tem pesado contra a aceitação em áreas de negócio acostumadas a dashboards e ferramentas externas. Um componente Kanban nativo encurta essa distância sem exigir código.

Não é uma revolução de arquitetura — é um componente de UI. Mas é exatamente o tipo de melhoria que, somada a outras evoluções declarativas, reduz o volume de código customizado em orgs maduras e devolve autonomia para o time de administração.

Como o recurso está vinculado ao Spring '26, confirme a disponibilidade na sua org e valide o comportamento exato dos somatórios, a ordenação de colunas e os limites de campos antes de prometer entrega. Sandbox primeiro, sempre.