DATTA BPM — Fluxos de Trabalho com Triagem Integrada

Coordenar o caminho de centenas de casos — quem faz o quê, em que ordem, com que prazo — em planilhas e trocas de mensagem é receita para prazo perdido e etapa esquecida. Com o DATTA BPM você desenha o fluxo de trabalho visualmente em notação BPMN 2.0 (processo judicial, pedido de empréstimo, pedido de benefício social…), escolhe quais regras de triagem rodam em cada fase e acompanha cada caso em tempo real — com prazos que a plataforma cobra sozinha, decisões automáticas baseadas na triagem e relatórios consolidados no DATTABI.

Menu: DATTA BPM›Process Modeler e DATTA BPM›Process Monitor.

Conceitos

Como desenhar um fluxo no Process Modeler

1. Novo modelo: informe nome, descrição e o contexto de processos — a base que o fluxo orquestra (define o auto-início e o registro de processos existentes). Sem contexto, vale o contexto ativo da plataforma. O contexto é definido na criação e aparece como badge na barra do editor (não há seletor lá): as regras de triagem não dependem desse campo — são escolhidas dentro de cada tarefa ou decisão (item 4).
   • O contexto tem que existir no cadastro da plataforma. Um contexto preenchido que não está cadastrado é recusado na hora, com a lista dos contextos aceitos (as mesmas chaves que a plataforma usa — Processos, CPC, …). Deixar o campo em branco continua valendo e é o caminho para um fluxo que não se prende a um contexto. A verificação vale para os três caminhos de escrita: criar, editar e publicar — inclusive quando o contexto vem declarado no XML (datta:contexto), caso de arquivo .bpmn importado. Por que importa: a instância herda o contexto do modelo, então um contexto inexistente aqui produz instâncias que nunca conseguem ler a base — ficam sem responsável e sem título descritivo, e o sintoma só aparecia muito depois, no log de outro serviço.
   • Modelo antigo com contexto inválido continua editável: a verificação só recusa o valor que muda. Renomear, mexer no diagrama ou publicar um modelo que já estava gravado com um contexto inexistente não é bloqueado — do contrário seria impossível corrigir o próprio modelo pela tela.
   • Cadastro de contextos fora do ar não bloqueia: se a plataforma não consegue consultar a lista, o contexto informado é aceito e a ocorrência fica registrada no log do serviço. É verificação de forma, não de permissão: indisponibilidade de um serviço não pode impedir você de trabalhar.
2. Desenhe o fluxo arrastando elementos da paleta (padrão BPMN 2.0 — a mesma notação do Bizagi/Camunda Modeler). Elementos suportados: evento de início, evento de fim (inclusive terminate), tarefa de usuário, tarefa de serviço (triagem), subprocesso embarcado, chamada de processo, gateways exclusivo, paralelo e inclusivo, eventos de tempo e de mensagem (de início, intermediários e anexados a uma tarefa) e gateway por evento.
3. Campos do formulário de uma fase: selecione uma tarefa de usuário e, no painel de propriedades, defina os campos que o responsável preenche ao concluir a fase — cada campo tem nome (variável), rótulo, tipo (texto, número, sim/não, data, lista), se é obrigatório, opções (para lista) e valor padrão. No monitor, Concluir fase abre esse formulário tipado; campos obrigatórios bloqueiam a conclusão até serem preenchidos, e os valores viram variáveis usadas nas condições dos gateways. Compatível com BPMN 2.0 padrão: ioSpecification (dataInput/dataOutput = obrigatório) e property de modelos importados (Bizagi/Camunda) também viram campos.
4. Regras em qualquer tarefa ou decisão: selecione uma tarefa (de usuário ou de triagem) ou um gateway e clique em Selecionar regras — abre uma janela com filtro por contexto, busca semântica por nome ou texto da regra e seleção de uma ou mais regras. Cada item mostra o contexto legal da regra (CPC/CDC/CPP…).
   • Filtro por contexto: a lista traz todo contexto que tem regra ativa, com a quantidade ao lado (CPC (1.076)), mais a opção "Todos os contextos que posso ver". Contexto cujas regras estão todas inativas fica de fora — a janela só seleciona regra ativa, então a opção não levaria a lugar nenhum. Só aparecem os contextos que o seu usuário alcança — o recorte é feito no servidor, a partir dos workspaces de que você participa, e pedir um contexto fora do seu acesso responde "Você não tem acesso a esse contexto de regras" em vez de devolver uma lista vazia sem explicação.
   • Pré-seleção: como as regras são catalogadas por contexto legal (detectado por processo na triagem) e o modelo aponta para um contexto de processo (ex.: "Processos"), o contexto do modelo já vem escolhido quando tem regras próprias. Quando não tem, a janela abre em "Todos os contextos que posso ver" e diz por quê — antes ela exibia o catálogo inteiro sem avisar, e as regras pareciam ser as do contexto do modelo.
   • Contexto sem regra devolve lista vazia, com a explicação "Este contexto ainda não tem regras — escolha outro contexto no filtro".
   • Texto completo da regra: a lista mostra os primeiros 160 caracteres do enunciado; clique no texto (ou em Ver texto completo) para abrir um painel rolável com a regra inteira. Fecha com Esc, clique fora ou Fechar, e o foco volta para o item de onde saiu.
   • A busca semântica procura dentro do contexto escolhido no filtro.
   • Trocar de contexto não desfaz a seleção: as regras já marcadas continuam gravadas no modelo, inclusive as de outro contexto.
   • Marque "Falhar a fase se alguma regra retornar anomalia/erro" para que, ao chegar naquele ponto do fluxo, uma anomalia ou anomalia crítica faça a fase falhar (a instância vai para EM_ERRO, reexecutável no monitor). Sem a marcação, as regras só alimentam as variáveis usadas nas decisões e o fluxo segue.
   • As regras pertencem ao elemento, nunca ao modelo inteiro: cada tarefa e cada decisão tem a sua própria seleção. Um selo com a contagem aparece no canto da caixinha ou do losango no diagrama, para se ver de relance onde há triagem vinculada e onde ficou vazio.
   • Sem seleção, o comportamento difere por tipo: numa tarefa de triagem rodam TODAS as regras ativas do contexto; numa tarefa de usuário ou gateway não roda regra nenhuma. O painel avisa em cada caso.
   • Regras vinculadas a uma junção de caminhos paralelos (gateway paralelo ou inclusivo alcançado por mais de um caminho) não são executadas — ali o processo apenas espera os ramos irmãos. A validação recusa o modelo nesse caso, para a configuração não ficar morta em silêncio.
5. Condições de decisão: selecione uma seta que sai de um gateway exclusivo. A condição pode ser montada de duas formas, alternando no topo do painel:
   • Assistente (visual): linhas de condição no formato *variável + operador
     • valor — a variável vem de uma lista com o resultado da triagem* e os

     campos de formulário definidos nas fases do próprio diagrama; o valor é sugerido conforme o tipo (status da triagem, sim/não, opções de lista, número). Com mais de uma linha, escolha se o fluxo exige TODAS (E) ou QUALQUER (OU). A expressão gerada aparece embaixo e é a que fica salva no modelo.

   • Script: campo livre para expressões avançadas, ex.:

     qtdAnomalias > 0 && (statusTriagem == 'ANOMALIA' || temAnomaliaCritica)

Parênteses e mistura de E/OU só são editáveis aqui — o assistente avisa e mantém o modo script.

Marque uma das saídas como fluxo padrão. Variáveis preenchidas pela triagem: statusTriagem (CONFORME | ANOMALIA | ANOMALIA_CRITICA | INCONCLUSIVO), qtdAnomalias, qtdConformes, qtdSemContexto, qtdNaoAvaliadas, temAnomalia, temAnomaliaCritica, scoreTriagem — além das variáveis informadas ao concluir tarefas de usuário.

qtdSemContexto e qtdNaoAvaliadas são separadas de propósito, e a distinção decide roteamento: a primeira conta regras que a triagem avaliou e não encontrou o dado no processo; a segunda conta regras que a IA não chegou a avaliar porque a chamada ao modelo falhou. Até 2026-08-22 a segunda situação não existia como dado — a regra simplesmente sumia do laudo —, e uma condição escrita como qtdSemContexto == 0 passaria a mudar de ramo por causa de uma indisponibilidade do provedor. Se o seu fluxo precisa reagir a isso, escreva a condição sobre qtdNaoAvaliadas.

1. Prazos que a plataforma cobra sozinha (evento de tempo): arraste um evento de borda de tempo para cima de uma tarefa e informe a duração no formato ISO 8601 — PT48H (48 horas), P15D (15 dias), PT30M (30 minutos). O painel mostra a leitura em português ("dispara 48 horas depois de chegar aqui") e recusa formato inválido antes da publicação. Dois comportamentos, escolhidos no próprio painel:
   • Interromper a atividade (borda sólida): o prazo estourou → a tarefa é cancelada e o fluxo segue pelo caminho da borda. Use para perda de prazo.
   • Não interromper (borda tracejada): a tarefa continua e abre-se um caminho paralelo. Use para escalonamento — "avisa o supervisor, mas o analista segue trabalhando". Com ciclo (R/PT24H), lembra a cada 24 horas.

Também dá para usar um evento de tempo no meio do fluxo (o processo simplesmente espera aquele período) e um evento de início por tempo, que cria instâncias sozinho numa data (timeDate) ou periodicamente (R/PT24H). O prazo continua contando mesmo com a plataforma reiniciada — nada se perde.

1. Esperar algo de fora (evento de mensagem): um evento de mensagem faz o processo parar até que um sistema externo avise que algo aconteceu (juntada de documento, resposta do réu, retorno de outro sistema) — sem ninguém precisar ficar olhando o painel. Dê um nome à mensagem (ex.: documento-juntado); a correlação usa por padrão o número do processo, e o integrador publica a mensagem pela API do DATTA (veja a referência de API) informando o nome, a chave de correlação e as variáveis:

   {"nome": "documento-juntado", "correlacao": "0007580-15.2012.4.04.0000",
    "variaveis": {"tipoDocumento": "contestacao"}}

As variáveis enviadas entram no processo e podem ser usadas nas decisões. No monitor, Enviar mensagem faz o mesmo pela interface. Um evento de início por mensagem cria uma instância nova quando a mensagem chega, e um evento de envio avisa outros processos DATTA que esperam por ela.

Se nenhum processo estava esperando, a mensagem é descartada (comportamento padrão do BPMN) e a resposta avisa que nenhum destinatário foi alcançado — publique de novo quando o processo chegar na espera.

1. "O que vier primeiro" (gateway por evento): para o padrão aguardo a resposta por até 15 dias; se não vier, sigo por outro caminho, use o gateway por evento com duas saídas — uma para um evento de mensagem, outra para um evento de tempo. O primeiro que acontecer decide o caminho e cancela o outro.
2. SLA (horas): prazo informativo por fase, exibido no monitor e nos relatórios. Para um prazo que a plataforma cobra de fato, use o evento de borda de tempo (item 6).
3. Salvar: no rascunho, "Salvar" grava o diagrama sem publicá-lo, e Ctrl+S (Cmd+S no Mac) faz o mesmo pelo teclado. Salve quantas vezes quiser antes de publicar.
4. Validar e publicar: a validação aponta problemas estruturais em português (ex.: fase sem saída, gateway sem condições). Publicar torna o modelo executável. Para alterá-lo depois há dois caminhos, descritos no item 12: gravar direto na versão publicada (preservando as instâncias em andamento) ou criar uma nova versão (deixando-as na versão atual).
5. Salvar alterações em um modelo já publicado: abrir um modelo PUBLICADO mostra o selo Somente leitura e o diagrama continua editável. Ao salvar, você escolhe entre duas saídas — a diferença entre elas é o que acontece com as instâncias que já estão rodando:
   • Salvar (ação primária) grava direto na versão publicada, sem trocar de versão. As instâncias em andamento são preservadas na etapa em que estão e passam a seguir o fluxo novo a partir dali. É o caminho para corrigir um fluxo em produção sem parar o que já está em execução. Antes de gravar, uma confirmação mostra quantas instâncias serão preservadas.
   • Salvar como nova versão cria o rascunho da próxima versão com as suas alterações e deixa você nele, com "Salvar" e "Publicar" de volta. As instâncias em andamento continuam na versão atual, com o desenho de hoje, e só os processos novos usam a versão nova.

Quando o salvar direto é recusado: se alguma instância em andamento estiver parada numa etapa que o seu desenho remove, ela não teria para onde ir — o modelador nomeia as etapas e as instâncias afetadas e oferece a nova versão, que por definição não mexe no que está rodando. Renomear, mover, reconectar ou acrescentar etapa não cai nesse caso; só remover a etapa onde há instância parada.

Ambos exigem a permissão BPMN_DEPLOY; sem ela, o selo explica que a versão não pode ser alterada e nenhum dos dois botões aparece. Ctrl+S (Cmd+S) dispara a ação primária — e, como ela abre a confirmação, o atalho nunca grava sem você ver o impacto.

1. Exportar/Importar troca o XML BPMN 2.0 com ferramentas externas (Bizagi, Camunda Modeler).
2. Auto-início (modelo publicado): marque "Iniciar automaticamente a cada novo processo do contexto" no card do modelo para que todo processo NOVO do contexto entre no fluxo sem passo manual (ver seção abaixo).
3. Excluir modelo: o card de qualquer modelo tem "Excluir". Instâncias em andamento ou em erro bloqueiam a exclusão (conclua ou cancele antes); modelos com instâncias finalizadas pedem uma segunda confirmação para apagar também o histórico (eventos e resultados). A ação é auditada e irreversível.

Como um registro (processo, pedido, benefício) entra no fluxo

Cinco formas de associar um caso real a um modelo:

1. Manual, pelo monitor — Iniciar processo: escolha o modelo, informe a chave de negócio e, opcionalmente, variáveis iniciais (ex.: valor=50000, renda=8000) que alimentam as condições dos gateways. Números e true/false são convertidos automaticamente. Útil para fluxos manuais (esteira de trabalho sem triagem) — funciona como um formulário leve do caso.
2. Automático pós-ingestão — ligue o auto-início num modelo publicado. Todo processo NOVO que entrar no contexto (Upload, DATTA Extract, pipeline ou integração) inicia uma instância sozinho. Processos que já existiam quando você ligou a opção NÃO são reprocessados (baseline); há um teto por ciclo para não inundar a fila de triagem e de IA.
3. Registrar processos existentes (backfill) — no card de um modelo publicado, Registrar existentes cria uma instância para CADA processo já existente no contexto (ex.: registrar todos os processos judiciais no rito do CPC). As instâncias nascem paradas na primeira fase — nenhuma triagem é disparada no registro; já registrados são ignorados, então dá para rodar de novo sem medo. Complementa o auto-início, que cobre apenas os processos novos a partir de agora.
4. Pelo Painel de Processos — na tela de detalhamento de um processo, use Atribuir a modelo BPM... para registrá-lo num modelo publicado; Acompanhar no monitor abre a instância criada.
5. Por integração — sistemas externos e o próprio pipeline de ingestão podem criar instâncias informando o modelo, a chave de negócio, o título e as variáveis iniciais; veja a referência de API.

A chave de negócio é o elo com os dados: numa tarefa de triagem, a plataforma busca o processo correspondente na base do contexto e roda as regras da fase contra ele. Se a chave ainda não existir na base, a fase de triagem falha (reexecutável após a ingestão). Fluxos só com fases manuais aceitam qualquer chave.

O que aparece no Process Monitor

• Iniciar processo: escolha um modelo publicado, informe a chave de negócio (ex.: número do processo) e variáveis iniciais opcionais. A plataforma percorre o fluxo automaticamente até a primeira fase manual.
• Lista de instâncias com filtros por modelo e chave, atualizada ao vivo — o indicador "ao vivo" acende quando há eventos.
• Os totalizadores são o filtro de status: os cards Instâncias / Em andamento / Concluídas / Em erro / Canceladas são clicáveis — clicar aplica o status, clicar no card já ativo volta para todas. Não há uma linha separada de botões de status: o número e o filtro são o mesmo controle.
• O título diz QUAL processo é: para processo judicial o título traz a classe processual e a parte principal (ex.: "Mandado de Segurança — FUSOPAR PARAFUSOS LTDA"), com o número na coluna Chave. Título escrito por quem iniciou o processo (ex.: "Pedido R$ 50k — Ana") é preservado. O título vem da base do contexto na leitura, sem regravar a instância: corrigiu o dado na base, o monitor acompanha.
• Só lista processo que existe: instância cuja chave de negócio não existe mais na base do contexto fica fora da lista e do total. Se a base do contexto estiver indisponível, nada é escondido — prefere-se mostrar demais a esconder processo válido.
• Selo "contexto não cadastrado": instância cujo contexto não existe no cadastro da plataforma aparece com um selo âmbar ao lado da chave (e no campo Contexto do detalhe). Passe o mouse para a explicação: o processo continua executando normalmente, mas o enriquecimento que vem da base do contexto — responsável e título descritivo — não se aplica, porque não há base para ler. A instância não é escondida: esconder o problema tiraria o rastro dele. Modelos novos não caem mais nisso (o contexto é verificado na criação); o selo serve às instâncias criadas antes dessa verificação. Se a plataforma não conseguir consultar o cadastro, nada é marcado — marcar por indisponibilidade acusaria contexto válido de inexistente. Quem tem BPMN_DEPLOY clica no selo e vai direto à correção: o diálogo Trocar o contexto do modelo abre já apontando para o modelo que gerou aquela instância (seção Trocar o contexto de um fluxo).
• Selo "segue o contexto ativo" / "não segue o modelo": selo roxo, ao lado da chave e no campo Contexto do detalhe, para a instância que não segue o contexto que o modelo dela declara. É uma pergunta diferente do selo âmbar acima e não pode ser confundida com ele: lá o contexto não existe na plataforma; aqui ele existe, mas esta instância não o acompanha. Duas causas:
  • "segue o contexto ativo" — a instância não tem contexto fixado, e contexto em branco significa "resolver pelo contexto ativo da plataforma a cada leitura". Enquanto isso, o modelo declara outro. É um estado legítimo (e por isso o selo só explica, sem oferecer correção): trocar o contexto do modelo não fixa essa instância. O detalhe mostra para onde ela resolve de fato — "ativo da plataforma (hoje Processos) — o modelo declara OnboardingPJ". O "hoje" é literal: o contexto ativo é global e pode mudar depois que a tela carregou, então a frase descreve o momento, não promete.
  • "não segue o modelo" — a instância tem um contexto explícito diferente do que o modelo declara (acontece quando o modelo foi repontado sem migrar as instâncias). Aqui há o que corrigir: quem tem BPMN_DEPLOY clica no selo e cai no diálogo Trocar o contexto do modelo, com a migração marcada.
• Detalhe da instância: diagrama com a fase atual destacada (azul), fases concluídas (verde) e erros (vermelho); linha do tempo de eventos; resultados das regras por fase (com explicação da IA); variáveis atuais.
• Regras por etapa: como as regras são vinculadas a cada tarefa ou ponto de decisão (não ao modelo inteiro), o painel Resultados das regras traz uma pastilha por etapa com a contagem anomalias/total — clicar recorta a lista para aquela etapa. Etapas com anomalia ficam destacadas em vermelho. Clicar na caixinha (ou no losango) do diagrama faz o mesmo recorte e contorna a etapa selecionada; clicar de novo volta para Todas as etapas. Dentro de cada grupo as anomalias vêm primeiro e o cabeçalho resume "N anomalia(s) em M regra(s)".
• Ações: Concluir fase numa fase manual (informando variáveis opcionais), Reexecutar regras numa fase que falhou e cancelar a instância (histórico preservado). O cancelamento vale para instâncias em andamento e em erro — útil quando a fase que falhou não será reexecutada (ex.: desistência); instâncias concluídas ou já canceladas não podem ser canceladas. Triagens que estiverem executando no momento do cancelamento são interrompidas e resultados tardios são descartados. Cancelar uma instância filha (chamada de processo) marca a fase de chamada do pai como erro, reexecutável. Cancelar um pai com chamadas em voo cascateia: todas as instâncias filhas (e netas) ainda ativas são canceladas junto, cada uma com o próprio histórico preservado e o motivo "O processo chamador foi cancelado".
• Exclusão do processo na plataforma: ao excluir um processo no painel Processos, as instâncias BPM daquele número (incluindo chamadas de processo) são removidas automaticamente do monitor — com histórico — e o número volta a ser elegível ao início automático caso o processo seja recarregado. Diferente do cancelar (que preserva o histórico no monitor), essa remoção acompanha a exclusão do próprio processo.
• Prazos e esperas: uma fase parada num evento de tempo mostra a contagem regressiva ("dispara em 2h 14min"); uma tarefa com prazo anexado mostra o relógio do prazo no próprio card. Fases esperando mensagem mostram o nome da mensagem esperada e o botão Enviar mensagem, que publica a mensagem correlacionada com aquele processo. Quando o gateway por evento está ativo, o monitor lista os candidatos ("aguardando o que vier primeiro"). Na linha do tempo aparecem Aguardando evento, Prazo cumprido, Prazo expirado (âmbar), Mensagem recebida/enviada e Evento decidiu o caminho.
• Relatórios (aba): instâncias por status, fases concluídas × tempo médio, gargalos (aguardando agora, com SLA), anomalias por regra e série diária. O painel Anomalias por regra de triagem tem pastilhas de etapa: por padrão soma o modelo inteiro, e escolher uma tarefa/decisão mostra só as anomalias daquela etapa — útil porque cada etapa tem sua própria seleção de regras, e a soma do modelo mistura seleções diferentes.
• Gerar dashboard DATTABI: cria no DATTABI um dashboard consolidado do modelo (KPIs, status, gargalos, anomalias por regra, série temporal) que pode ser publicado em qualquer workspace.
• Abrir modelador: leva direto ao diagrama do processo aberto — com uma instância no detalhe, abre o modelo dela; na lista, abre o modelo do filtro. Sem instância nem filtro (não há um diagrama único a apontar) cai na galeria de modelos.

Trocar o contexto de um fluxo

Contexto errado no modelo acontece — o fluxo nasceu antes do contexto ser cadastrado, ou o nome digitado não era o do cadastro. Como a instância herda o contexto do modelo, corrigir só o modelo deixaria as instâncias apontando para o lugar antigo. A plataforma faz as duas coisas numa operação só, com prévia do impacto e registro em auditoria.

Onde fica

• No Process Modeler: o contexto na barra do editor é um botão — clique nele (ou em Definir contexto, quando o modelo não tem nenhum). Vale também para modelo publicado: contexto é política de execução, não desenho.
• No Monitor: clique no selo contexto não cadastrado da instância, na lista ou no detalhe. Ele leva ao modelo que gerou a instância — é lá que o contexto mora.

O que a prévia mostra (antes de qualquer escrita)

Escolhido o destino, o diálogo mostra, lado a lado, de onde e para onde o enriquecimento passa a ler: o banco do contexto, a entidade (label) e a propriedade de identificação de cada lado. Mais as contagens: quantas instâncias seriam migradas, quantas já estão no destino, quantas seguem o contexto ativo e o total. O botão de confirmar só habilita depois que a prévia aparece e o motivo é preenchido — trocar o contexto muda de qual base vem o dado, e confirmar isso às cegas é o tipo de decisão que só se descobre errada depois.

Quando há instâncias sem contexto fixado, a prévia não se limita a dizer que elas ficam de fora: ela diz para onde elas resolvem, com o contexto ativo daquele momento — "2 instância(s) seguem o contexto ativo (hoje Processos) e continuarão seguindo; como o destino é OnboardingPJ, elas vão resolver para Processos, não para OnboardingPJ." Se a plataforma não conseguir ler qual é o contexto ativo agora, a frase diz isso, em vez de prometer um destino que ninguém apurou.

O que muda e o que não muda

• Muda: o campo contexto do modelo e o das instâncias dele que têm contexto explícito (quando a migração é marcada). O datta:contexto declarado no diagrama é realinhado junto, para a próxima versão publicada não desfazer a troca.
• Não muda: status, fase atual, tokens, variáveis, chave de negócio e histórico das instâncias. Instância em execução continua exatamente onde estava — o que muda é de onde vem o enriquecimento, não o estado do fluxo.
• Nada é copiado entre bancos. A instância passa a ler de outro contexto; nenhum dado é movido de uma base para outra. E nenhuma instância é apagada.

A regra do contexto em branco

Instância sem contexto fixado nunca é migrada — nem por esta troca, nem pela cascata da renomeação de um contexto. Contexto em branco não quer dizer "sem contexto": quer dizer "resolver pelo contexto ativo da plataforma a cada leitura". Gravar um nome ali converteria uma escolha dinâmica em fixa sem ninguém ter pedido — e, o ponto decisivo, sem volta: depois que o nome está gravado, não há mais como saber quais instâncias eram dinâmicas. Não tocar é recuperável; tocar não é. Entre o reversível e o irreversível, a plataforma escolhe o reversível.

O preço dessa regra é uma divergência legítima — o modelo declara Y, a instância resolve pelo ativo — e ela é anunciada, nunca silenciosa: aparece na prévia (acima) e no monitor, no selo "segue o contexto ativo" da lista e no campo Contexto do detalhe. Quem quiser fixar uma instância nessas condições faz isso deliberadamente, não por efeito colateral de outra operação.

Regras

• Destino tem que estar cadastrado: contexto inexistente é recusado com a mesma mensagem da criação do modelo, listando as chaves aceitas.
• Motivo é obrigatório e vai para a auditoria (BPMN.MODELO.CONTEXTO_ALTERADO, com quem trocou, origem, destino e quantidade).
• Idempotente: instância que já está no destino não é tocada nem entra na contagem de migradas. Repetir a operação não muda nada.
• Instância sem contexto fixado fica de fora (ver A regra do contexto em branco): ela não entra em "a migrar" nem em "continuam no contexto anterior" — é contada à parte, porque nunca seria migrada de todo jeito.
• É por modelo, nunca "mova tudo que é KYB": o modelo carrega a intenção e a instância só herda — uma migração por contexto atravessaria modelos de donos diferentes, e um motivo só não explicaria nenhum deles. Modelo com várias versões: repita a troca em cada versão que tiver instâncias.
• Permissão: BPMN_DEPLOY (a mesma de editar/publicar modelo). Sem ela, o selo continua explicando o problema, mas não oferece a ação.

Responsável pela instância

Toda instância tem um responsável — a pessoa que responde por aquele caso. Ele serve para acompanhar e filtrar; não é permissão: quem tem BPMN_EXECUTE continua podendo concluir qualquer fase, esteja ela sob sua responsabilidade ou não.

De onde vem

1. Da atribuição feita no Painel de Processos. Ao atribuir um processo a um usuário, a plataforma grava o responsável no processo e o propaga para as instâncias BPM daquela chave de negócio. Instância criada depois disso nasce com o responsável vigente.
2. Da própria tela. Na lista e no detalhe, clique no responsável (ou em Sem responsável) para atribuir ou reatribuir. Deixar o campo em branco libera a instância — voltar para "sem responsável" é um estado legítimo, não um erro.

Cada troca fica registrada na trilha de auditoria como BPMN.INSTANCIA.RESPONSAVEL_ALTERADO, com quem alterou, de quem para quem.

Como filtrar

Na aba Instâncias e na aba Relatórios, a barra de filtros tem o campo Responsável, com sugestão dos usuários cadastrados, mais dois atalhos:

O filtro combina com modelo, situação e chave de negócio. Nos relatórios ele vale para os quatro blocos ao mesmo tempo (resumo, fases, anomalias por regra e série diária) — o relatório e a lista respondem ao mesmo filtro, então os números batem. Reclicar no atalho aceso limpa o filtro.

Histórico anterior ao recurso

Instâncias criadas antes deste recurso nascem sem responsável e aparecem em Sem responsável. Um administrador pode preencher o histórico de uma vez a partir das atribuições já existentes; a operação é idempotente (reexecutar só alcança o que falta) e informa quantas instâncias continuam sem responsável. O recurso correspondente está descrito na referência de API.

Exemplo prático — esteira de triagem com prazo

1. Em DATTA BPM›Process Modeler, crie o modelo "Rito ordinário — triagem" no contexto "Processos": início → tarefa de triagem → gateway exclusivo → (conforme) fim; (anomalia) tarefa de usuário "Revisão do analista" → fim.
2. Na tarefa de triagem, use Selecionar regras e escolha as regras de prazo e intimação. Na seta de anomalia do gateway, use o assistente: temAnomalia + é verdadeiro; marque a outra saída como fluxo padrão.
3. Arraste um evento de borda de tempo (interruptivo, P5D) para a tarefa "Revisão do analista", desviando para "Escalar ao supervisor".
4. Publique. No card do modelo, clique em Registrar existentes para colocar o acervo atual no fluxo e ligue o auto-início para os novos.
5. Acompanhe em DATTA BPM›Process Monitor: os casos com anomalia param na revisão; se o analista não concluir em 5 dias, a plataforma desvia sozinha para o supervisor. Feche o ciclo com Gerar dashboard DATTABI para a visão executiva.

Permissões

Solução de problemas

• "Triagem falhou" / instância em erro: verifique a disponibilidade da IA e use Reexecutar regras na fase. A plataforma também se recupera de reinícios marcando execuções interrompidas para reexecução.
• "Nenhuma das regras selecionadas está ativa": a regra foi desativada/excluída no cadastro de regras após a publicação — publique uma nova versão do modelo com a seleção atualizada.
• Processo não avança após a triagem: confira as condições do gateway — se nenhuma condição é satisfeita e não há fluxo padrão, a instância entra em erro com mensagem indicando o gateway.
• "O contexto '…' não está cadastrado na plataforma": o contexto informado no modelo (ou declarado no XML importado) não existe no cadastro. A mensagem lista os contextos aceitos — use um deles, deixe o campo em branco, ou cadastre o contexto em Sistema›Contextos e tente de novo (o cadastro novo é reconhecido na hora, sem esperar cache).
• Instância com o selo "contexto não cadastrado": o contexto do modelo que originou aquela instância não existe (ou não existe mais) no cadastro. Duas saídas, nenhuma delas exigindo linha de comando: apontar o modelo para o contexto certo — clique no selo e use Trocar o contexto do modelo, que migra as instâncias junto (seção Trocar o contexto de um fluxo) — ou cadastrar o contexto com o mesmo nome em Sistema›Contextos, quando o nome gravado é o correto e só faltava o cadastro. Nenhuma instância é apagada por causa disso: remover histórico é decisão de quem opera.
• A prévia diz "este contexto não identifica os dados por uma entidade": não é erro. Nem todo contexto ancora seus dados numa entidade raiz — um corpus de código processual (CPC, CDC, CPP) guarda artigos, e um grafo de referência guarda dados de consulta. Para esses, não há "processo" a enriquecer: título e responsável ficam como foram gravados na instância. Contextos que ancoram declaram a entidade e a propriedade identificadora no cadastro (Sistema›Contextos) — por exemplo Empresa/cnpj num dossiê cadastral. Um modelo apontado para contexto sem âncora também não inicia processos automaticamente nem aceita registro em lote: nos dois casos o gatilho é a entidade raiz, e a plataforma diz isso em vez de devolver zero em silêncio.
• Uma instância sumiu do filtro por contexto: a plataforma monitora esse caso. Os filtros comparam o contexto por igualdade exata (é o que mantém a busca rápida), e um valor gravado com espaço nas bordas — vindo de importação ou de restauração de backup antigo — não casaria com o nome limpo. O serviço confere isso a cada reinício e publica a métrica bpmn_contexto_com_padding, que deve ser 0; acima disso, o log registra um aviso e a correção é renomear ou reapontar o contexto, que normaliza o valor.
• Monitor lista processos que não existem mais no painel Processos: são órfãs de limpezas em massa feitas por fora da plataforma, anteriores à exclusão em cascata. O time de operação tem um procedimento de saneamento.
• O prazo passou e o processo não desviou: a varredura de prazos roda a cada 15 segundos, então o disparo pode atrasar até um ciclo — normal. Se passar muito disso, confira o modelo: um prazo só vale enquanto o caso estiver na tarefa vigiada; se a fase foi concluída antes, o prazo é desarmado de propósito (não há disparo póstumo).
• "Nenhum processo estava aguardando esta mensagem": não é erro. Ou o processo ainda não chegou na espera, ou a chave de correlação não bate — por padrão ela é o número do processo (chave de negócio). Confira a chave enviada e publique de novo; mensagens não ficam guardadas esperando destinatário.
• O filtro por responsável devolve tudo vazio: confira em Sem responsável. Instâncias criadas antes deste recurso, ou de processos que nunca foram atribuídos, ainda não têm dono — atribua no Painel de Processos ou peça ao administrador o preenchimento do histórico (seção Responsável pela instância).
• Atribuí o processo no painel e a instância continua sem responsável: a propagação é imediata, mas depende do monitor estar no ar no momento da atribuição. Reatribua pela própria tela do monitor ou repita a atribuição no painel; a operação é idempotente.
• "Este modelo não tem diagrama": o modelo foi publicado sem o desenho do fluxo, então não há o que exibir no modelador nem no monitor. O processo continua executando normalmente — as instâncias andam e o painel de fases mostra o progresso; só o diagrama fica indisponível. Para vê-lo, publique uma nova versão com o fluxo desenhado. Modelos novos não caem mais nisso: publicar sem desenho é recusado na validação.
• "O XML pode estar corrompido": diferente do caso acima — aqui o arquivo em si não é legível (importação de .bpmn truncado ou editado à mão). Reimporte o arquivo original ou redesenhe o fluxo no modelador.
• O modelo não publica com evento de tempo: a expressão precisa ser ISO 8601 (PT48H, P15D, R/PT24H). A mensagem de validação aponta o elemento e o formato esperado. Ciclos abaixo de 60 segundos são recusados de propósito, para não criar tempestade de instâncias.