Dicionário de componentes de gerenciamento de casos do Maestro

Dicionário de referência para componentes do Maestro Case, incluindo chaves de casos, estágios, tarefas, regras, personas, SLAs e superfícies de gerenciamento de runtime.

	Caso do Maestro	BPMN do Maestro	Fluxo do Maestro
O conteúdo aplica-se a	✅	❌	❌

Visão geral

Este documento de referência fornece um detalhamento factual de todos os componentes do Gerenciador de casos do Maestro. Use-o como um dicionário para entender o que é cada construção quais propriedades ela expõe e como ela se relaciona com outras construções. Para obter orientação passo a passo sobre como criar um caso, consulte o tutorial de Gerenciamento de casos.

Público-alvo: intermediário a avançado — desenvolvedores de automação, arquitetos de soluções e gerentes técnicos.

Status do produto: disponível para o público geral.

Como as construções se relacionam

A hierarquia a seguir mostra como as construções do gerenciamento de casos se encaixam durante o design e no runtime.

Case (runtime instance, identified by Case Key)

DESIGN-TIME (Studio Web)
├── Case Manager (rules-based orchestration)
├── Case Personas (human roles, scoped to stages)
└── Case Plan (visual blueprint)
    ├── Event Triggers
    └── Stages + Stage Transitions (entry / complete / exit / re-entry)
        └── Tasks (Human, Agent, External Agent, RPA, Connector,
                    API Workflow, Agentic Process, Child Case,
                    Wait Timer, Wait Event, Ad-hoc)

CROSS-CUTTING
└── SLAs & Escalations (case-level and stage-level)

RUNTIME
├── Case App (business users — view, track, act)
└── Case Instance Management (operators — pause, resume, cancel, migrate, retry)

---

Chave do caso

A chave de caso identifica de forma exclusiva uma instância de caso no Maestro e sistemas externos.

TipoDeChave	Description	Exemplo
Chave do sistema	Gerado automaticamente pelo Maestro na criação de casos. Usa um prefixo constante configurável.	HC-1234, CLM-00891
Chave externa (definida pelo cliente)	Um ID externo informado na criação do caso para que o mesmo caso do mundo real seja reconhecido em todas as ferramentas.	Número do caso no CRM, número da política, ID do pedido no ERP

Configure a chave de caso ao criar o tipo de caso no Studio Web. Selecione Chave de prefixo constante e forneça uma string de prefixo (por exemplo, HO-). O Maestro acrescenta um identificador incrementado automaticamente.

Use uma chave externa quando o caso se origina em outro sistema (CRM, ERP, ferramenta de emissão de tickets), e usuários humanos ou integrações devem correlacionar o caso entre diferentes ferramentas sem manter uma tabela de mapeamento separada.

---

Estágios

Um estágio é uma fase nomeada no ciclo de vida do caso (por exemplo, Recebimento, Revisão, Liquidação). Os estágios são as colunas na tela do plano do caso, cada um agrupando tarefas relacionadas que são executadas durante essa fase.

Tipos de estágios

O Maestro oferece suporte a duas categorias de estágios:

Tipo	Description	Exemplo
Estágio primário	Representa a progressão de caminho ideal de um caso.	Recebimento, Revisão, Liquidação, Fechamento
Estágio secundário	Representa caminhos de exceção que se ramificam do fluxo primário. Pode retornar à origem ou ser terminal.	Pendente com o cliente, Negado, Retirado

Propriedades do estágio

Propriedade	Description
name	Nome de exibição (por exemplo, "Enviado", "Revisão do gerente").
required	Se o caso deve passar por esse estágio para ser concluído. Se true e a regra de entrada nunca é avaliada como verdadeira, o caso é bloqueado. Se false, o caso pode ser concluído mesmo se este estágio nunca tiver sido acessado.
entryRule	Condição que deve ser verdadeira para que esse estágio seja ativado.
completeRule	Condição que determina quando esse estágio termina. Muitas vezes "quando todas as tarefas necessárias são concluídas".
exitRule	Condição de saída antecipada. Quando atendida, o estágio termina imediatamente, mesmo se a regra completa não tiver sido satisfeita.
reentryCondition	Condição que permite que um caso retorne a esse estágio para retrabalho.
autoComplete	Marque automaticamente o estágio como concluído quando todas as tarefas necessárias forem finalizadas.
runOnReentry	Controla se o estágio é redefinido e reexecutado quando reinserido após a conclusão anterior. Padrão: false.
sla	Limite de tempo para conclusão do estágio (dias úteis ou dias calendário).

Estágios necessários versus opcionais

	Estágio obrigatório	Estágio opcional
Conclusão do caso	O caso não pode terminar até que esse estágio termine.	O Caso pode terminar mesmo se você nunca entrar nesse estágio.
Quando usar	Fases principais pelas quais todo caso deve passar (por exemplo, "Enviado", "Pagamento").	Fases condicionais que se aplicam apenas às vezes (por exemplo, "Revisão de VP" para casos de alto valor).
Comportamento se a Regra de Entrada nunca é verdadeira	Blocos de casos.	O caso pula o estágio.

Comportamentos de saída do estágio secundário

Comportamento	Description	Exemplo
Voltar à origem	Quando todas as tarefas no estágio secundário terminarem, o caso retorna ao estágio que o enviou.	Um estágio Pendente com o cliente retorna à Revisão após o recebimento dos documentos.
Terminal	Quando todas as tarefas no estágio secundário terminam, o caso finaliza.	Um estágio Negado fecha o caso após enviar um pacote de negação.
Entrada orientada por conector	O estágio secundário fica ativo quando um evento de conector externo chega, independentemente de qual estágio primário o caso ocupa.	Um estágio Retirado entra automaticamente quando o Microsoft Teams publica uma mensagem de canal.

Executar no comportamento de reentrada (estágios)

runOnReentry	Comportamento	Use case
true	O estágio volta para Ativo. Todas as tarefas são reavaliadas — tarefas necessárias com runOnReentry: true são executadas novamente.	Loop de correção: é preciso revalidar o estágio "Enviado" após a rejeição.
false (Padrão)	O estágio permanece Concluído. A reentrada é sem operações. O sistema preserva os resultados anteriores.	Estágios únicos que devem ser executados apenas uma vez (por exemplo, "Entrada inicial").

---

Tipos de tarefas

Uma tarefa é uma unidade discreta de trabalho dentro de um estágio. As tarefas são os blocos de construção atômicos do processamento de casos.

Tipos de tarefas compatíveis

Tipo de Tarefa	Description	Exemplo de uso
Humano (Ação)	Atribuído a uma pessoa por meio de uma persona. Abre um formulário ou item de trabalho na fila do Aplicativo do caso.O humano revisa, toma uma decisão e envia.	Aprovação do gerente, revisão do ajustador, aprovação de finanças.
Agente (UiPath)	Um agente de IA da UiPath executa raciocínio autônomo sobre dados. Útil para trabalho baseado em julgamentos.	Categorize despesas, sinalize anomalias, elabore uma resposta ao cliente.
Agente externo	Invoca um agente de IA de terceiros fora da UiPath (por exemplo, por meio do protocolo A2A ou da API). Habilita a orquestração de agentes de vários fornecedores.	Chame um agente de conformidade externo de um sistema de parceiro.
Fluxo de trabalho de RPA	Dispara um robô da UiPath para executar UI Automation em sistemas legados onde não existe API.	Processe o reembolso em um sistema de folha de pagamento legado, insira dados em um mainframe.
Conector (Integration Serviços)	Chama um sistema externo por meio de um conector pré-criado ou personalizado. Executa de forma síncrona ou assíncrona com retorno de chamada.	Procure detalhes da política no Salesforce, execute uma verificação de crédito.
Fluxo de trabalho da API	Chama um sistema externo por meio de uma solicitação de API personalizada.Executa de forma síncrona ou assíncrona com retorno de chamada.	Acione o software de agendamento para obter slots disponíveis, crie novo tíquete.
Processo baseado em agentes do Maestro	Invoca um processo baseado em agentes do Maestro (baseado em BPMN) como uma tarefa. O processo executa com sua própria orquestração e retorna um resultado.	Fluxo de trabalho de auditoria de várias etapas com sua própria lógica de agente.
Gerenciamento de casos (caso filho)	Gera outra definição de caso como um caso filho. O filho tem seu próprio ciclo de vida, estágios e tarefas, vinculados ao pai por meio de caseID.	Um caso de sinistros gera um caso de investigação de fraude filho.
Aguardar temporizador	Pausa a execução até que uma duração especificada expire ou que uma data/hora de destino seja atingida.	Aguarde 48 horas antes de enviar um aviso de acompanhamento.
Aguardar evento do conector	Pausa a execução até que um evento externo chegue por meio de um conector (webhook, fila de mensagens, retorno de chamada do sistema).	Aguarde uma confirmação de pagamento do sistema bancário.

Tarefas ad-hoc

As tarefas ad-hoc são criadas no runtime por um usuário humano quando é necessária uma tarefa não planejada que não faz parte do plano de caso original. Por exemplo, um processador de casos humanos adiciona um caractere "Solicitar documentação adicional" tarefa durante a investigação.

Propriedades da tarefa

Propriedade	Description
name	Nome de exibição.
type	Um dos: human, agent, externalAgent, rpa, connector, agenticProcess, childCase, waitTimer, waitEvent, adhoc.
required	Se o estágio pai deve esperar que essa tarefa termine. Se true, o estágio não pode terminar até que a tarefa se encerre. Se false, o estágio pode terminar mesmo se essa tarefa não tiver terminado.
entryRule	Condição que determina quando essa tarefa começa. Habilita a execução condicional (por exemplo, executar apenas quando amount >= 1000).
completeRule	Condição que determina quando se considera essa tarefa concluída.
exitRule	Condição de saída antecipada para a tarefa. Quando atendida, a tarefa termina imediatamente.
runOnReentry	Se se redefine e se reexecuta essa tarefa, se reinsere o estágio pai. Padrão: false.
linkedWorkflow	Referência ao fluxo de trabalho de implementação, formulário ou configuração do agente.
assignment	Para tarefas humanas: a persona, usuário, equipe ou regra de roteamento que determina o destinatário.
sla	Para tarefas humanas: hora de conclusão, limites de advertência e destinatários de escalonamento.

Tarefas obrigatórias versus opcionais

	Tarefa obrigatória	Tarefa opcional
Conclusão do estágio	O estágio pai não pode concluir até que você finalize esta tarefa.	O estágio pai pode terminar mesmo se você não concluir esta tarefa.
Quando usar	Trabalho obrigatório (por exemplo, "Aprovação do gerente" no estágio de revisão).	Trabalho desejável (por exemplo, "Sinalizar anomalias" — útil, mas o estágio pode prosseguir sem ele).
Interação de preenchimento automático	Se o estágio tiver autoComplete: true, a conclusão aguarda todas as tarefas necessárias.	Não se considera na verificação de preenchimento automático.

Executar com base no comportamento de reentrada (tarefas)

runOnReentry	Comportamento	Use case
true	Você redefine e reexecuta a tarefa, produzindo uma nova saída.	Tarefas de validação que devem verificar novamente os dados corrigidos.
false (Padrão)	A tarefa retém seu resultado anterior; não executa novamente.	Tarefas cuja saída ainda é válida (por exemplo, "Categorizar despesas" não precisa nova execução).

---

Condições

Condições (também chamadas de condições ou regras de transição) controle o movimento do ciclo de vida nos níveis de estágio e de tarefa. O Maestro oferece suporte a quatro tipos de condições.

Condição para entrada

Avalia com base nos campos de casos. Quando a condição se torna verdadeira, o estágio ou tarefa faz a transição de Disponível para Ativo.

Escopo	Description	Exemplo
Estágio	Controla o início de um estágio.	vars.validationPassed == true ativa o estágio Revisão.
Tarefa	Habilita a execução condicional de uma tarefa dentro de um estágio ativo.	Executar apenas quando amount >= 1000.

Condição concluída

Define quando um estágio ou tarefa termina em circunstâncias normais. Para estágios, isso geralmente é "quando todas as tarefas necessárias terminam". Para tarefas, normalmente é "quando a tarefa produz saída".

Escopo	Description	Exemplo
Estágio	Marca um estágio como concluído quando o trabalho termina.	Todas as tarefas necessárias terminaram.
Tarefa	Marca uma tarefa como concluída ao receber sua saída.	taskOutput.status != "error".

Condição de saída (saída antecipada)

Um mecanismo de saída antecipada. Quando a condição for atendida, o estágio ou tarefa termina imediatamente — mesmo se a regra completa não tiver sido satisfeita. As condições de saída atuam como disjuntores para cenários anormais ou condicionais.

Escopo	Description	Exemplo
Estágio	Encerra um estágio antes que todas as tarefas terminem.	vars.action == "Reject" encerra o estágio Revisão, e o caso se move para o estágio secundário Negado.
Tarefa	Interrompe uma tarefa antes de sua conclusão normal.	policyValid == false interrompe a validação adicional.

Observação:

Não confunda condições de saída com condições de conclusão. Uma condição concluídadispara quando o trabalho termina (finalização normal). Uma condição de saída dispara quando algo muda, o que significa que o trabalho deve parar (saída antecipada). Ambos resultam no Gerenciador de caso avaliando qual estágio entrar em seguida.

Condição para entrada nova

Permite que um caso retorne a um estágio concluído anteriormente de maneira estruturada e auditável. Esse recurso permite fluxos de casos não lineares para loops de retrabalho controlados.

Escopo	Description	Exemplo
Estágio	Retorna o caso para um estágio anterior quando é necessário trabalho adicional.	vars.decision == "Claim is missing key incident reports" retorna o caso de Revisão para Recebimento.

Quando ocorre a reentrada, configurar quais tarefas específicas reexecutar dentro do estágio de destino. Tarefas com runOnReentry: true executam novamente; tarefas com runOnReentry: false retêm seus resultados anteriores.

Pular regra

Uma condição opcional em um estágio que ignora totalmente o estágio quando a condição é verdadeira.

Escopo	Description	Exemplo
Estágio	Ignora um estágio quando ele não é aplicável.	riskScore < 30 ignora o estágio de investigação detalhada.

---

SLAs e escalonamentos

Defina SLAs (Acordos de Nível de Serviço) e regras de escalonamento nos níveis de caso e estágio para impor expectativas baseadas em tempo.

Níveis de SLA

Nível	Description	Exemplo
SLA no nível de caso	Destino geral para a resolução de caso da criação até o fechamento.	Resolva o sinistro em 48 horas úteis.
SLA no nível de estágio	Prazo localizado para um estágio específico.	Conclua a Entrada FNOL dentro de 4 horas; Revisão do Gerente dentro de 24 horas.

Estados do SLA

Estado	Description
Em andamento	O caso ou estágio está dentro do período alocado.
Em Risco	O SLA está se aproximando de seu limite (por exemplo, em 80% do período alocado).
Violada(s)	O limite de tempo do SLA foi excedeu.

Os estados de SLA aparecem como selos em listas de casos e visualizações de detalhes dentro do Aplicativo do caso.

Regras de escalonamento

Gatilho	Description	Ação típica
Escalonamento em risco	Acionado quando o SLA está se aproximando de seu limite.	Notificar o proprietário do caso e o supervisor.
Escalonamento de violações	Disparado quando o SLA é excedido.	Reatribua para um trabalhador sênior, notifique a gerência, crie um sinalizador de prioridade.

Pausar e retomar

Você pode pausar os temporizadores de SLA quando o caso estiver aguardando uma entrada externa (por exemplo, uma resposta do cliente) e retomá-los quando o caso se tornar acionável novamente.

---

Gerenciador de caso

O Case Manager orquestra o ciclo de vida do caso usando regras determinísticas. As regras lidam com padrões conhecidos e previsíveis.

Como o gerenciador de casos funciona

1. Evento recebido — um gatilho dispara e cria (ou atualiza) uma instância de caso.
2. Avaliação de regra — o Gerenciador de caso avalia as condições de entrada de todos os estágios para determinar quais estágios devem se tornar ativos.
3. Ativação de tarefas — dentro de estágios ativos, o sistema avalia as condições de entrada das tarefas para iniciar o trabalho apropriado.
4. Monitoramento — à medida que as tarefas terminam, o Gerenciador de caso avalia as condições de conclusão (término normal) e condições de saída (resgate antecipado).
5. Conclusão do caso — quando todos os estágios necessários terminam, o caso se fecha.

Escopo das regras

Você pode definir as regras (entrada, conclusão, saída) em três níveis:

• Nível de caso — governa o ciclo de vida geral do caso (quando o caso termina?).
• Nível de estágio — controle as transições do estágio (quando esse estágio deve ativar, concluir ou encerrar?).
• Nível de tarefa — controle a ativação e a conclusão de tarefas individuais.

Baseado em regras versus gerenciador de caso com agente

	Baseado em regras	Agêntico
Lógica de orquestração	Condições determinísticas de entrada/completa/saída definidas pelo desenvolvedor do caso.	Um agente de IA decide quais tarefas executar, quais estágios de transição e como o caso é resolvido.
Configuração	Regras no nível do estágio e da tarefa (consulte Condições).	Um agente com um contrato de entrada e saída definido (consulte Contrato de entrada e saída do Case Manager).
Quando usar	Padrões conhecidos e previsíveis.	Orquestração baseada em julgamento que não se reduz a regras fixas.

As regras e o agente não são duas alternativas independentes — quando um plano de caso usa ambos, as regras são avaliadas primeiro em cada evento. Suas decisões recomendadas passam para o agente como contexto, e as próprias decisões do agente são o que o Maestro atua.

Configuração do gerenciador de casos

Configuração	Description
model	O LLM que alimenta o agente (por exemplo, claude-3.5-sonnet, gpt-4o).
userPrompt	Instruções do sistema que definem a função, as políticas e as restrições do agente.
tools	Ações que o agente pode executar (por exemplo, mover estágio, escalonar, enviar notificação).
context	Memória para o agente, que se cria automaticamente com base no histórico de execução. O agente acumula contexto de decisões anteriores, resultados de tarefas e alterações de estados de casos.

Para a forma exata de entrada (caseCurrentExecutionState) e saída (caseManagerDecisions) que o agente deve usar, consulte Contrato de entrada e saída do Gerenciador de caso.

Observação:

Se o Gerenciador de caso não puder tomar uma decisão — devido a dados ambíguos, regras conflitantes ou um cenário fora de suas políticas — ele escalona automaticamente para intervenção humana.

---

Personas do caso

As personas de caso definem as funções de participantes humanos que interagem com um caso durante seu ciclo de vida. As personas controlam quem pode visualizar e agir dentro de cada estágio. Personas são para pessoas, não para agentes. Você configura os agentes de IA separadamente como tipos de tarefa.

Tipos de personas integrados

Persona	Role	Recursos típicos
Criador de casos	Inicia o caso — envia o gatilho original (formulário do portal, chamada de API, e-mail).	Criar novas instâncias de casos; visualize o status dos casos que eles criaram; capacidade limitada de atualizar casos abertos antes da conclusão do primeiro estágio.
Proprietário do caso	Responsável pelo caso de ponta a ponta. Geralmente se atribui na criação.	Visibilidade completa de casos em todos os estágios; pode reatribuir tarefas, substituir decisões (dentro da política), reabrir casos fechados.
Trabalhador de caso	Executa tarefas humanas atribuídas dentro de estágios específicos.	Visualize e conclua tarefas em sua fila (Meu trabalho); atualize os campos de casos com escopo para sua saída de sua tarefa; visibilidade apenas no nível de estágio.
Supervisor/Gerente	Supervisiona o portfólio de casos de uma equipe; lida com escalonamentos.	Visualizar todos os casos atribuídos à sua equipe; reatribuir tarefas; aprovar escalonamentos; pausar/retomar temporizadores de SLA; acessar painéis e KPIs.
Especialista em assunto (SME)	Consulta em casos ou estágios específicos que exigem conhecimento especializado.	Acesso de leitura a dados de casos relevantes; pode concluir tarefas designadas por SME; não tem permissões amplas de gerenciamento de casos.

Além dos tipos integrados, os desenvolvedores de casos podem criar personas personalizadas — dar um nome à persona e definir seu escopo para um ou mais estágios específicos. As personas personalizadas não aparecem automaticamente em todos os lugares.

Permissões de personas no nível do estágio

Para cada estágio no plano de caso, defina duas dimensões de acesso para cada persona:

• Acesso de visualização — quais personas podem ver os dados, tarefas e histórico desse estágio no Aplicativo do caso.
• Acesso de ação — quais personas podem adotar medidas dentro desse estágio (concluir tarefas, adicionar notas, reatribuir, escalonar, disparar transições).

As tarefas herdam as configurações da persona do estágio por padrão, mas podem restringir ainda mais as funções permitidas.

Estratégias de atribuição

Strategy	Como funciona	Quando usar
Estático	Você atribui um usuário, equipe ou grupo fixo no período de design.	Tarefas que sempre vão para a mesma equipe (por exemplo, a Revisão de finanças sempre vai para o grupo Finanças).
Dinâmico	Uma regra ou expressão resolve o destinatário no runtime.	Atribuição com balanceamento de carga de trabalho, roteamento por território/região, roteamento baseado em habilidades.

Observação:

A compatibilidade com as funções e acesso de usuários de casos ainda não está disponível.

---

Aplicativo do caso

O Aplicativo do caso é o aplicativo de runtime voltado para o usuário empresarial, onde os trabalhadores de casos, gerentes e outras personas do caso visualizam, rastreiam e agem em instâncias de casos ativas.

O que os usuários de negócios veem

Exibir	Description
Lista/fila de casos	Visualização filtrável de todas as instâncias de casos, com status, prioridade e indicadores de SLA (no prazo, em risco, violado).
Visualização de detalhes do caso	Estágio atual, status das tarefas, linha do tempo de eventos e trilha de auditoria completa.
Caixa de entrada de tarefas (Meu trabalho)	Tarefas humanas pendentes que aguardam ação: formulários, aprovações, revisões.
Ações	Ações contextuais baseadas na função e no estágio atual: concluir, reabrir, escalonar, reatribuir, adicionar notas, solicitar informações, criar tarefas ad-hoc.
Painéis	KPIs agregados: taxa de transferência, período de resolução, conformidade com SLA, identificação de gargalos.

Configuração

Configure o Aplicativo do caso a partir da opção Configurar aplicativo do caso nas configurações do Gerenciador de casos dentro do Studio Web. Os elementos configuráveis incluem:

• Título do caso — o título de exibição que aparece na lista de casos e nas visualizações de detalhes.
• Detalhes do caso — os campos e o layout que aparecem na visualização de detalhes do caso.

Aplicativo do caso versus aplicativos da UiPath

Aspecto	Aplicativo do caso	UiPath Apps
Finalidade	WorkSpace opinativo e centrado em casos — listas, detalhes, tarefas, incidentes e visualizações de SLA para operações de casos.	Construtor de baixo código de uso geral para Apps empresariais totalmente personalizados ou compostos.
Quando usar	Operações rápidas de casos com visualizações prontas para uso.	Requisitos de interface gráfica personalizados além das operações de casos.

Você continua criando formulários de tarefas humanas com Apps de Ação, que são referenciados por tarefas de caso.

---

Gerenciamento de instâncias de caso

Case Instance Management é o console de operações onde os operadores de processos monitoram e gerenciam todas as instâncias de casos em execução.

Ações do operador

Ação	Description
Pausar	Pause temporariamente uma instância de caso em execução. Pausa dos temporizadores de SLA. As tarefas não são ativadas até que você as retome.
Retomar	Reinicie um caso pausado. Os temporizadores de SLA retomam a partir de onde pararam.
Cancelar	Encerrar uma instância de caso permanentemente. O sistema interrompe todas as tarefas em execução.
Migrar	Mover uma instância de caso ativa para uma versão mais recente do plano de caso (por exemplo, após uma correção de bug ou atualização do plano), preservando seu estado e dados atuais.
Tentar novamente	Execute novamente a tarefa ou a transição com falha para se recuperar de erros transitórios.
Atualizar variáveis	Modifique os valores da variável de caso em uma instância em execução para desbloquear o processamento.

Incidentes de caso

Quando uma instância de caso entra em um estado de erro (por exemplo, uma tarefa falha, uma integração expira ou o caso fica preso), ela se torna um incidente de caso. Os operadores de processo usam Migrar, Tentar novamente e Atualizar variáveis para resolver incidentes.

---

Gatilhos de evento

Gatilhos de eventos são os pontos de entrada em um caso. Eles definem o que inicia um caso e de onde vêm os dados. Um plano de caso único pode ter vários gatilhos.

Tipo do Gatilho	Origem	Exemplo
Formulário/Portal	O usuário envia por meio de um formulário da Web.	O funcionário envia um relatório de despesas por meio de um portal.
Email	E-mail de entrada analisado para dados.	O e-mail de recibo encaminhado cria um novo caso.
API	O sistema externo chama o ponto de extremidade da criação do caso.	O sistema ERP dispara um caso de sinistro em um evento de política.
Fila / Evento	Mensagem de uma fila ou fluxo de eventos.	O tópico do Kafka publica um novo evento de pedido.
Agendado	Gatilho baseado em tempo.	Uma verificação diária cria casos de acompanhamento para itens obsoletos.
Evento de entidade do Data Fabric	Um evento no nível de linha em uma entidade do Data Fabric ou VDO (por exemplo, "Linha criada").	Uma nova linha na entidade de Sinistros Residenciais dispara um caso.
Aguardar conector	Um evento de conector do Integration Service (por exemplo, mensagem do canal do Microsoft Teams publicada).	Uma mensagem do Teams dispara uma entrada de estágio Retirado.

Cada gatilho mapeia os dados de entrada para campos de casos.

---

Cobrança e consumíveis

• Sem faturamento separado para o Gerencdiador de caso do Maestro
• O trabalho executado dentro de um caso consome os consumíveis nativos dos tipos de tarefas usados:
  • Agentes de IA
  • Processos baseados em agentes do Maestro (Processos BPMN)
  • Fluxos de trabalho de RPA
  • Fluxos de trabalho/integrações de API

---

Glossário

Termo	Definição
Tarefa ad-hoc	Uma tarefa criada no runtime (não faz parte do plano de caso original) por um usuário humano quando uma ação não planejada é necessária.
Caso	Uma instância de runtime que representa uma situação de negócios do mundo real que precisa de resolução (um sinistro, disputa, investigação, exceção). Identificação por uma chave de caso.
Aplicativo do caso	O aplicativo voltado para o usuário empresarial, onde as pessoas visualizam, rastreiam e agem em instâncias de casos ativas.
Comentários de caso	Objeto pronto para uso que armazena notas, anotações e threads de comunicação, vinculados por meio do caseID imutável.
Documentos de casos	Objeto pronto para uso que armazena arquivos e anexos relacionados ao caso, que o caseID imutável vincula.
Incidente de caso	Um estado de erro em uma instância de caso (falha de tarefa, tempo limite de integração, caso preso) que requer intervenção do operador.
Gerenciamento de Instância de Caso	Console de operações no Maestro, onde os operadores de processo visualizam todas as instâncias de casos em execução e executam ações: pausar, retomar, cancelar, migrar, tentar novamente.
Chave do caso	Identificador exclusivo para uma instância de caso. O sistema pode gerar esse valor ou ele pode ser definido externamente/pelo cliente.
Case Manager	Mecanismo de orquestração que usa regras determinísticas.
Persona do caso	Uma função de participante humano com escopo nos estágios específicos. Tipos integrados: Criador do caso, Proprietário do caso, Trabalhador do caso, Supervisor/Gerente, SME. Os desenvolvedores podem criar personas personalizadas.
Plano de caso	Blueprint visual definindo estágios, tarefas, gatilhos e regras. Descreve os possíveis caminhos, não uma sequência fixa. Projetado no Studio Web.
Condição concluída	Condição que determina quando um estágio ou tarefa terminou em circunstâncias normais.
Condição para entrada	Condição que deve ser verdadeira para que um estágio ou tarefa seja ativado.
Gatilho de evento	Ponto de entrada que cria ou influencia uma instância de caso. Mapeia os dados de entrada para campos de casos.
Condição de saída	Condição de saída antecipada. Quando atendido, o estágio ou tarefa termina imediatamente, mesmo se a regra concluída não tiver sido satisfeita.
Estágio primário	Um estágio na progressão de caminho ideal de um caso.
Condição para entrada nova	Condição que permite que um caso retorne a um estágio concluído anteriormente para retrabalho.
Required	Sinalizador em estágios e tarefas. Você deve concluir os estágios necessários para o caso fechar.Tarefas obrigatórias devem terminar para que o estágio termine.
Executar na nova entrada	Sinalizador que controla se um estágio ou tarefa é redefinido e reexecutado quando reinserido após a conclusão anterior.
Estágio secundário	Um estágio que representa um caminho de exceção que se ramifica do fluxo primário. Pode retornar à origem ou ser terminal.
Pular regra	Condição opcional em um estágio que ignora totalmente o estágio quando a condição é verdadeira.
SLA	Contrato de Nível de Serviço. Expectativa baseada em tempo para conclusão de Caso ou estágio, com estados: no prazo, em risco, violado.
Estágio	Uma fase nomeada no ciclo de vida do caso que agrupa tarefas relacionadas. Governado por condições de entrada, conclusão, saída e reentrada.
Tarefa	Uma unidade de trabalho discreta dentro de um estágio. Dez tipos de tempo de design: Humano, Agente, Agente externo, RPA, Conector, fluxo de trabalho de API, Processo com agente, Caso filho, Temporizador de espera, Evento de espera. As tarefas ad-hoc são criadas no runtime.

---

Recursos relacionados

• Tutorial de gerenciamento de casos — instruções passo a passo para criar um caso a partir do zero.
• Designer de plano de caso no Studio Web — Referência para a tela de design visual.
• Documentação dos Apps de ação — como criar formulários para Tarefas humanas referenciadas pelas tarefas de casos.