Decisões DMN
Nível de acesso requerido
Admin ou Super Admin. A tela inteira — listar, implantar, alterar, testar e excluir — é restrita a esse papel; quem não o tem é levado de volta ao Dashboard.
A avaliação de uma tabela continua aberta a Gerente e Usuário pela API (POST /api/a/decisions/{chave}/evaluate), e é assim que os processos a consultam em nome de quem executa a tarefa. O que é restrito é a tela.
O módulo Decisões lista e gerencia as tabelas de decisão (DMN) implantadas no seu tenant. São as regras de negócio que os processos consultam para decidir um caminho ou calcular um valor.
A tela fica em Modelagem → Tabelas de Decisão, ao lado de Catálogo de Processos.
O que é uma tabela de decisão?
Uma tabela de decisão tem uma linha por regra. As colunas da esquerda são as entradas — o que o processo informa — e as da direita são as saídas — o que a tabela devolve.
Exemplo — quem aprova uma compra:
| Valor | Categoria | → Aprovador |
|---|---|---|
| ≤ 1.000 | Qualquer | Gerente direto |
| ≤ 10.000 | Qualquer | Diretor financeiro |
| > 10.000 | Qualquer | Comitê de compras |
Quantas linhas respondem, e o que acontece quando mais de uma corresponde, é definido pela hit policy declarada na própria tabela. Na política FIRST, vale a primeira linha que corresponde, de cima para baixo — é o comportamento do exemplo acima. Em UNIQUE, que é o valor assumido quando a tabela não declara nada, espera-se que uma só linha corresponda. Outras políticas devolvem mais de um resultado. A hit policy de cada tabela aparece em Detalhes, e é por isso que a ordem das linhas importa em umas e não importa em outras.
Vendo as tabelas implantadas
- Abra Modelagem → Tabelas de Decisão
- A lista traz o nome, a chave e a versão de cada tabela do tenant
- Clique em Detalhes para abrir a tabela abaixo da lista, só para leitura: a hit policy, as colunas de entrada, as de saída, uma linha por regra e a coluna Nota com a anotação de cada regra
Detalhes é a forma de conferir uma tabela sem risco de alterá-la. Fechar recolhe o quadro.
Implantando uma nova tabela
As tabelas são implantadas a partir dos templates DMN globais cadastrados pelo Super Admin.
- Abra Modelagem → Tabelas de Decisão
- Clique em Deploy Decisão
- Na janela Deploy Decision Table, escolha o Template global
- Clique em Deploy
A tabela é implantada com as regras do template e passa a valer para o tenant na hora. Não existe modelador nesse caminho: para ajustar as regras depois, use XML, descrito adiante. Se a lista de templates vier vazia, a janela avisa — nesse caso é o Super Admin quem precisa cadastrar o template antes.
Enviar um arquivo .dmn direto
A plataforma aceita implantar um arquivo .dmn sem passar por template, mas esta tela não oferece o botão: o caminho é a API (POST /api/a/decisions, com o arquivo no campo file). Veja Referência da API.
Alterando as regras de uma tabela
A alteração vale imediatamente
Uma tabela alterada muda o comportamento das próximas avaliações, inclusive das instâncias que já estão correndo e ainda não chegaram ao ponto de decisão. Altere com atenção, e use Testar antes de considerar o trabalho pronto.
Na linha da tabela, clique em XML. Abre a janela Editar XML com o conteúdo da tabela em texto; altere e clique em Redeploy para publicar uma versão nova. A versão exibida na lista sobe.
O editor visual de tabelas — aquele em que se clica na célula para editar, e em que se acrescenta e se remove linha — não fica aqui: ele é o modelador dos templates DMN, e só o Super Admin o alcança, em Global (Super Admin) → DMN Templates ou em Catálogo de Processos → Nova Definição → DMN Template. Um ajuste que deva valer para todos os tenants pertence ao template; um ajuste só deste tenant é feito aqui, no XML.
Excluir remove a tabela implantada do tenant. O template global não é afetado.
Testando antes de valer
O botão Testar avalia a tabela sem envolver processo nenhum:
- Clique em Testar na linha da tabela
- Escreva as variáveis de entrada (JSON) — por exemplo
{"valor": 5000, "categoria": "TI"} - Clique em Avaliar
O resultado aparece na própria janela, com as saídas que a tabela devolveu. JSON malformado é recusado com aviso, antes de qualquer chamada.
É o passo recomendado depois de cada Redeploy: uma regra escrita com o operador errado não falha, ela devolve outra coisa — e sem esse teste a diferença só apareceria na próxima instância.
Tipos de condição
| Tipo | Exemplo |
|---|---|
| Igual | "aprovado" |
| Comparação numérica | < 1000, >= 5000 |
| Intervalo | [100..500] (inclusivo) |
| Lista | "SP","RJ","MG" |
| Qualquer | (célula vazia — sempre verdadeiro) |
Impacto nas instâncias em andamento
Alterações nas tabelas de decisão valem imediatamente para novas avaliações. Instâncias que já passaram pelo ponto de decisão não são reavaliadas: o resultado que elas gravaram continua valendo.