AutoflowTrilha 04 · Autoflow visão geral
Do fluxo à tarefa: ciclo de vida
Rascunho, versão, processo, tarefa, incidente. Cada coisa no Autoflow nasce, muda de estado e termina segundo regras precisas. Quem domina esse ciclo sabe responder na hora perguntas como "se eu mudar o formulário, o que acontece com os pedidos em andamento?".
A linha do tempo de um fluxo
Só no seu navegador
Enquanto você desenha, o rascunho fica salvo localmente no navegador (por chave do fluxo). O motor não sabe que ele existe. Dá para importar e baixar o .bpmn.
Vira versão no motor
Publicar no Camunda (Ctrl+S) valida o desenho e cria uma versão imutável: v1, v2, v3…
Processos nascem na última versão ativa
Cada Novo processo cria uma instância na última versão não desativada. Ela fica nessa versão até o fim.
Faça o laboratório: publique, inicie dois processos, avance um, publique a v2, inicie outro, desative a v1. Observe o que acontece com cada processo.
Imagine que um processo está na etapa 3 de 5 e alguém apaga a etapa 4 do desenho. O que o motor faria? Para não ter essa pergunta, o Camunda (e o Autoflow) nunca altera uma versão publicada. Cada mudança cria uma versão nova, e cada processo segue o desenho com o qual nasceu. É mais seguro e auditável — o preço é que não há “correção retroativa”.
O que a publicação leva junto
Ao publicar, o Autoflow não envia só o desenho. Ele:
- roda o validador (erros bloqueiam; avisos perguntam “Publicar com avisos?”);
- anexa a versão atual de cada formulário referenciado e “prende” esses formulários à versão do fluxo;
- registra quais requisitos de documentos e regras o fluxo usa (para o sistema saber o que está “em uso”).
Republicar sem mudar nada não cria versão nova. Qualquer mudança — inclusive só num formulário — cria.
Três coisas que NÃO ficam presas à versão
| Item | Vínculo | Consequência |
|---|---|---|
| Formulários | Presos à versão do fluxo (binding “deployment”) | Publicar formulário novo não muda processos em andamento nem novos: é preciso republicar o fluxo |
| Regras de negócio | “latest” | A versão publicada vale na próxima avaliação de todos os processos, inclusive os em andamento |
| Solicitação de documentos | Subprocesso “latest”; a política (itens, validadores, prazo) é congelada ao abrir cada solicitação | Mudar o requisito afeta as próximas solicitações, não as já abertas |
| Anexos permitidos | Valem na hora | Inclusive para processos em andamento |
O cliente pede um campo novo no formulário. Você publica a versão nova do formulário e avisa que está pronto. Nada muda. Motivo: formulários estão presos à versão do fluxo. O Autoflow avisa (“Versão 3 salva. Para valer em execução, publique o processo…”), mostra o selo Formulários desatualizados na lista de fluxos e oferece o botão Republicar processos que usam este formulário. Use-o.
Ciclo de vida de um processo (instância)
Ciclo de vida de uma tarefa
Além disso: Encaminhar passa a tarefa para um colega da unidade (permissão Encaminhar) e Reatribuir muda o responsável de qualquer tarefa (permissão de supervisor, que também libera a aba Todas).
Se duas analistas do mesmo cargo abrissem e preenchessem a mesma tarefa ao mesmo tempo, uma perderia o trabalho. Assumir é a “trava”: deixa claro quem está com o caso. Explique isso no treinamento — usuários novos estranham o clique extra.
Incidentes: quando o motor não consegue seguir
Um incidenteIncidente — Falha técnica que parou um processo (ex.: integração fora do ar, gateway sem saída). Aparece em Monitoramento › Incidentes e pode ser retentado. acontece quando uma etapa automática falha: o sistema do despachante não respondeu, uma regra deu erro, um gateway não tinha saída, uma tarefa de serviço tem um tópico sem tratador. O processo fica parado naquele ponto.
Onde ver e agir:
- Monitoramento › Incidentes e a aba Incidentes do processo: Retentar, Pular (só etapas automáticas) e Corrigir variáveis.
- No Console Super, o painel de saúde mostra incidentes por organização, e a investigação de processo mostra a causa provável.
Erros de integração tratáveis (o parceiro recusou os dados) não precisam virar incidente: modele um evento de borda de erro para desviar o fluxo para uma tarefa de correção.
O que dá e o que não dá para fazer depois
| Pergunta do cliente | Resposta |
|---|---|
| Posso mudar uma etapa de um processo que já está rodando? | Não. Ele termina na versão em que nasceu. “Migrar processos…” existe na tela, mas está desabilitado pendente. |
| Posso apagar uma versão errada? | Não. Desative a versão (ninguém mais inicia nela). Opcionalmente, suspenda os processos dela. |
| Posso excluir um fluxo? | Só se nunca teve processo. Caso contrário, desative. |
| Posso voltar um processo uma etapa? | Não pelo produto. Modele caminhos de devolução no fluxo (“pendência volta para quem devolveu”). |
| Mudei a regra; os processos antigos usam a nova? | Os que ainda vão passar pela regra, sim. Os que já passaram, não. |
Resumo
- Rascunho é local; publicar cria uma versão imutável; processos nascem na última versão ativa e ficam nela.
- Formulários são presos à versão: depois de publicar formulário, republique o fluxo.
- Regras valem “latest”; a política de documentos congela por solicitação; anexos permitidos valem na hora.
- Processo: em andamento → suspenso / concluído / cancelado; incidentes param etapas automáticas.
- Tarefa: na fila → assumida → concluída; tarefas do iniciador só saem por reatribuição.