AutoflowTrilha 05 · Área da empresa
Fluxos: modelar e publicar
O fluxo é o coração do Autoflow. Aqui você aprende o editor, os blocos próprios do sistema, as validações antes de publicar, como funciona o versionamento e como ler dois fluxos reais que rodam em produção.
Onde fica
Administração › Modelagem › Fluxos — exige process.model. Publicar, ativar e desativar versões exige process.publish. Por padrão só o Administrador do grupo tem as duas.
A lista mostra: Fluxo, Versão, Em andamento, Incidentes, Publicado em, e o selo Formulários desatualizados quando algum formulário tem versão mais nova do que a publicada no fluxo.
Menu de cada linha: Editar, Iniciar processo, Visualizar (diagrama com simulação de tokens), Duplicar, Configurar cartão, Configurar métricas e Excluir fluxo (só se nunca teve processo).
Publicar coloca o fluxo em produção para todos. Separar process.model de process.publish permite que um analista de processos desenhe e teste, enquanto o dono do processo (ou o admin) revisa e publica. É o mesmo princípio de “quatro olhos” usado em controle interno.
Criar um fluxo do zero
- Clique em Novo fluxo. Se o cliente tem segmento (Concessionária, Advocacia), abre um diálogo com Em branco e os modelos do pacote (“A partir de modelo”).
- Preencha os Detalhes do fluxo: Chave do processo (ex.:
SOLICITACAO_REEMBOLSO— vira o id do processo, não muda depois), Nome da publicação, Descrição e o ícone (presets ou Enviar imagem). - Desenhe no canvas. É o editor bpmn-js completo com o painel de propriedades Camunda. O diagrama vazio já vem com processo executável,
historyTimeToLive=180e um evento “Início”. - Configure cada tarefa de usuário: formulário (seletor “Form reference”) e responsável —
${initiator}no Assignee, ou grupo candidato no Candidate groups. - Use os blocos do Autoflow para documentos, regras, prazos e integrações (tabela abaixo).
- Teste com a simulação de tokens (“Simular aqui”) antes de publicar.
- Clique em Publicar no Camunda (atalho Ctrl+S). O validador roda; erros bloqueiam, avisos pedem “Publicar mesmo assim”.
Como dizer quem faz cada tarefa
O Autoflow não usa raias para atribuir trabalho — use-as só para documentar. Quem recebe a tarefa é definido nela mesma:
| Configuração na tarefa | Efeito | Exemplo |
|---|---|---|
Assignee ${initiator} |
Vai direto para quem abriu o processo | “Corrigir pendência” |
Candidate groups pos:CARGO |
Fila de todos com esse cargo na unidade | pos:GERENCIA_COMERCIAL |
dept:id |
Fila de todos do departamento | Financeiro |
dept:id+pos:CARGO |
Só quem tem os dois | Gerente do Financeiro |
| Vários separados por vírgula | Qualquer um deles | pos:ADVOGADO,pos:ADVOGADO_SOCIO |
${variavel} vinda de regra |
Atribuição dinâmica (saída tipo Cargo) | ${aprovador} |
Prefira pos:CARGO em fluxos novos (a chave nua do cargo também funciona, por compatibilidade). O editor sugere os cargos existentes. E departamento casa pelo id exato — não há herança entre departamentos.
Os blocos próprios do Autoflow
Solicitação de documentos
Pede, recebe e valida documentos com base em um Requisito. Escolha o requisito, o modo de validação (sequencial/paralela) e a origem dos arquivos.
Regra de negócio
Avalia uma tabela DMN publicada. Cada saída vira variável do processo.
Calcular prazo (dias úteis)
Soma dias úteis usando o calendário da unidade. Grava prazo e prazoFim.
Enviar a sistema externo
Chama a API de outro sistema via uma integração cadastrada, com payload em modelo.
Aguardar retorno externo
Espera a mensagem de volta do parceiro. Combine com prazo de borda para cobrança.
Marco e Participante externo
Marco: etapa mostrada no acompanhamento (Ordem 1–999, Opcional). Participante externo: etapa feita no portal.
No Autoflow, toda tarefa de serviço precisa ser do tipo external com um tópico conhecido (integration.http.send, calendar:add-business-days, notification.send). Os blocos fazem isso por você. Uma tarefa de serviço “crua” é bloqueada pelo validador (serviceTask.notExternal). Tópico desconhecido gera aviso.
O validador antes de publicar
Erros que bloqueiam (os mais comuns na prática):
- processo não executável ou sem History Time To Live;
- id do processo diferente da chave informada;
- nenhum evento de início “simples” — ou mais de um;
- tarefa de serviço que não é external;
- formulário inexistente (com sugestão do nome mais próximo);
- Solicitação de documentos sem requisito, ou com requisito desconhecido;
- Regra de negócio sem regra, ou regra sem versão publicada;
- Calcular prazo sem dias ou com dias inválidos;
- mensagem de espera sem nome.
Avisos (permitem “Publicar mesmo assim”): tarefa de usuário sem formulário e sem responsável, tópico desconhecido, formulário arquivado ou de outra tarefa, integração que aceita recusa mas nenhum gateway testa o desfecho, papel externo sem campo de formulário.
O validador existe porque erro de modelagem só aparece em produção, com cliente real esperando. Tarefa sem responsável vira tarefa órfã; gateway sem fluxo padrão vira incidente. Leia cada aviso — eles são o “segundo par de olhos” do consultor.
Versões: o que acontece quando você republica
Este é o conceito que mais confunde cliente. Faça o laboratório abaixo: publique, inicie processos, avance tarefas, publique uma nova versão e inicie outro processo.
As regras:
- Rascunho fica só no navegador (localStorage por chave, com banner de restauração). O motor só conhece o que foi publicado. Use Baixar .bpmn para guardar cópia.
- Versão é imutável. Abrir a v2 e publicar gera a v3 (banner “Editando a partir da vN. Publicar cria a vN+1”).
- Republicar sem mudança não cria versão. Qualquer mudança — inclusive só num formulário vinculado — cria.
- Processos em andamento ficam na versão em que nasceram, com os formulários daquela versão. Não há migração: “Migrar processos…” aparece desabilitado.
- Desativar uma versão impede novos inícios nela; opcionalmente suspende os processos em andamento.
- Exceções que pegam sempre a mais recente: o subprocesso de documentos e as regras DMN (
latest). A política de documentos é congelada no momento em que cada solicitação abre.
Publicar uma versão de formulário não altera nada até você republicar o fluxo — e mesmo assim só vale para processos novos. A tela avisa e oferece Republicar processos que usam este formulário. Explique isso ao cliente antes que ele pense que “o sistema não salvou”.
Cartão e métricas
- Configurar cartão (“Cartão da listagem”): exibir imagem; Imagem da instância (variável com URL https de um domínio permitido, ou campo Registro de base); quais variáveis aparecem no cartão da caixa de tarefas e em que ordem. Isso é o que o operador vê sem abrir a tarefa — capriche.
- Configurar métricas: marca campos do formulário publicado como Dimensão (lista, opções, caixa), Medida (número) ou Período (data). Depois aparecem no painel Métricas.
Fluxo real 1: Venda de veículo novo
Este é o fluxo VENDA_DE_NOVOS usado em concessionárias. Clique nos elementos para ler o porquê de cada um. Repare: não há raias — os responsáveis estão nas tarefas.
Fluxo real 2: Primeiro emplacamento (com despachante)
Fluxo do pacote Concessionária. Ele mostra integração, espera de retorno, prazo de cobrança e tratamento de recusas.
Resumo
- Fluxos ficam em Modelagem › Fluxos; modelar (
process.model) e publicar (process.publish) são permissões diferentes. - Responsável é definido na tarefa (
${initiator},pos:,dept:), não pela raia. - Use os blocos do Autoflow: Solicitação de documentos, Regra de negócio, Calcular prazo, Enviar/Aguardar sistema externo, Marco, Participante externo.
- O validador bloqueia erros que virariam incidente; leia os avisos.
- Toda publicação é uma versão nova e imutável; processos rodando não migram; formulários só valem após republicar o fluxo.