Múltiplos Resultados de Decision Tables em Standard Expression Sets

O que é

Esse item resolve uma limitação específica de quem trabalha com Expression Sets e Decision Tables no ecossistema de Industries. Antes da Winter '27, quando uma decision table retornava múltiplos resultados que davam match para um único input, só era possível processar todos esses resultados se a expression set estivesse construída sobre uma context definition, ou seja, dentro do Context Service.

Com essa release, standard expression sets, aquelas que não usam Context Service, também podem consumir decision tables que retornam múltiplos outputs a partir de uma única entrada. Isso elimina uma bifurcação de arquitetura que existia até então: se você precisava de múltiplos resultados, era obrigado a adotar Context Service, mesmo que seu caso de uso não justificasse essa complexidade adicional.

O texto oficial não detalha a mecânica interna de como o Expression Set Builder agora expõe ou itera sobre esses múltiplos resultados, mas o ponto central é claro: a paridade de funcionalidade entre standard expression sets e expression sets baseadas em context definition aumentou nesse aspecto específico.

Por que importa

Na prática, isso reduz uma decisão arquitetural que muitos times enfrentavam cedo demais no design. Já vi projeto inteiro migrar para Context Service só por causa dessa limitação pontual de decision table, quando o caso de uso não pedia nada daquele overhead de modelagem de contexto. Context Service tem seu lugar, mas é uma decisão de plataforma, não deveria ser forçado por uma limitação pontual de decision tables.

Com essa mudança, você pode manter uma expression set standard, mais simples de manter e evoluir, e ainda assim lidar com regras de negócio que naturalmente produzem múltiplos outputs, como elegibilidade para vários produtos, múltiplas ofertas aplicáveis ou combinações de descontos. Isso simplifica o desenho de soluções que usam BRE (Business Rules Engine) em cenários de Industries sem empurrar todo mundo para Context Service por padrão.

Como se preparar

• Revise expression sets existentes que hoje dependem de Context Service unicamente por causa de múltiplos resultados de decision table, e avalie se elas podem ser simplificadas para standard.
• Ao desenhar novas decision tables, não assuma mais que múltiplos matches exigem context definition. Confirme na sua org se o comportamento já está disponível antes de definir a arquitetura.
• Documente com o time de negócio quais regras realmente precisam de múltiplos outputs simultâneos, para não sobrecarregar decision tables com lógica que poderia ser resolvida de forma mais simples.
• Se você já tem investimento pesado em Context Service por outros motivos, essa mudança não elimina o valor dele, apenas remove uma dependência artificial que existia antes.

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

Não exige código, mas envolve reavaliar decisões arquiteturais já tomadas em expression sets e decision tables existentes na org.

Considerações de arquiteto

• Guilherme recomenda mapear na sua org todas as expression sets que hoje usam Context Service apenas por causa de múltiplos resultados de decision table, antes de qualquer refatoração.
• É preciso validar se a simplificação para standard expression set realmente reduz manutenção sem quebrar integrações que já consomem a context definition atual.
• Vale alinhar com o time de negócio quais cenários de elegibilidade ou ofertas múltiplas justificam decision tables mais robustas, evitando lógica desnecessária.
• Se a org já tem Context Service maduro por outros motivos, a migração para standard não deve ser feita só por essa novidade, o valor da plataforma continua.

Pegadinhas:

• O artigo não detalha a mecânica de como o Expression Set Builder expõe os múltiplos outputs na standard expression set, então é preciso testar diretamente na sua org antes de assumir paridade total.

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