Trilha 09 · Método de implantação

Fase 5: configuração no Autoflow

Configurar o Autoflow tem uma ordem certa, ditada pelas dependências entre os cadastros. Seguir essa ordem evita voltar atrás, refazer convites e republicar fluxos. Esta lição traz a sequência completa, do provisionamento no Console Super às integrações, com o porquê de cada etapa.

Por que a ordem importa

Os cadastros do Autoflow se apoiam uns nos outros. Um fluxo só publica se os formulários, regras e requisitos que ele cita existirem e estiverem publicados. Um requisito de documentos cita tipos de documento, departamentos e cargos. Um convite de usuário exige cargo e unidade. Se você configurar fora de ordem, vai encontrar erros de validação na publicação — ou, pior, usuários convidados com o cargo errado.

A sequência completa

O diagrama a seguir resume as dependências. Cada seta significa “precisa existir antes”.

Organização (Super) ─► Unidades ─► Departamentos ─► Cargos ─► Calendário
                                         │             │
                                         ▼             ▼
            Bases de dados ─► Tipos de documento ─► Requisitos
                   │                                    │
                   ▼                                    ▼
              Formulários ──────► Regras ──────► FLUXO (publicar)
                                                        │
                                                        ▼
                    Cartão · Métricas · Anexos permitidos · Integrações
                                                        │
                                                        ▼
                                  Usuários (convites) · Participantes externos

Etapa 1 — Provisionar a organização (Console Super)

Em Console Super › Início › Nova organização, um operador de plataforma (platform-operator) informa Nome da organização, Segmento, E-mail do primeiro administrador, Motivo e confirma digitando o nome.

• Por quê primeiro: cria o grupo (tenant), o grupo raiz no Keycloak com os cargos de sistema (GROUP_ADMIN, MATRIX_MANAGER) e convida o primeiro administrador.
• Segmento: Concessionária ou Advocacia instalam um pacote pronto (departamentos, cargos, tipos de documento, requisitos, formulários, regras, calendário e modelos de fluxo), sem sobrescrever nada. Não pode ser trocado depois. Na dúvida, “Sem segmento” — dá para definir depois uma única vez.
• Se o convite falhar, o painel da organização oferece Convidar primeiro admin.

Etapa 2 — Primeiro acesso do administrador

O administrador do cliente aceita o convite, cria a senha e entra. Ele tem o cargo Administrador do grupo, o único cargo de sistema com permissão de modelar e publicar processos. Faça a configuração junto com ele: é o melhor treinamento que ele vai ter.

Etapa 3 — Unidades

Administração › Organização › Unidades: Adicionar matriz na linha do grupo (a filial “Sede — matriz” é criada automaticamente), Adicionar filial na linha da matriz, Editar dados fiscais (CNPJ único no grupo) e Personalizar tema (logo, ícone, cor).

• Por quê agora: vínculos de usuário, cargos de escopo Matriz/Filial, calendário e bases de dados dependem das unidades. E só com uma filial ativa é possível iniciar processos e trabalhar na caixa de tarefas.
• Não existe exclusão de unidade na interface: confira os nomes antes de criar.

Etapa 4 — Departamentos

Administração › Organização › Departamentos: Novo departamento para cada área funcional (Financeiro, Jurídico, Protocolo).

• Por quê antes dos cargos e requisitos: departamentos são usados em atribuição de tarefas (dept:<id>), em “Quem anexa” e nos validadores dos requisitos de documentos, e nos vínculos dos usuários.

Etapa 5 — Cargos e permissões

Administração › Organização › Cargos: Novo cargo com Chave (maiúsculas, imutável), Nome, Nível (Admin/Gerente/Membro), Escopo (Grupo/Matriz/Filial), Visibilidade (Toda a unidade / Somente os que eu iniciar / Cargos selecionados) e as permissões.

• Por quê agora: a chave do cargo é o que vai nos grupos candidatos das tarefas (pos:CHAVE), nos validadores de documentos, nas saídas do tipo Cargo das regras e nos convites.
• A chave é imutável: escolha nomes funcionais e estáveis (ANALISTA_FINANCEIRO, não ANALISTA_DA_MARIA).
• Cargos novos não recebem permissões automaticamente — marque uma a uma. Lembre que “Cancelar processo” exige Encerrar incidente (incident.terminate).

Etapa 6 — Calendário

Administração › Organização › Calendário: ligue as Datas móveis do grupo (Carnaval, Cinzas, Corpus Christi) conforme a realidade do cliente e cadastre feriados estaduais, municipais e recessos em Nova data, na unidade certa.

• Por quê antes de publicar o fluxo: o bloco Calcular prazo grava a data no momento em que roda. Editar o calendário depois não recalcula prazos já calculados. Se os feriados locais entrarem depois do go-live, os primeiros processos terão prazos errados.

Etapa 7 — Bases de dados

Administração › Bases de dados: crie a estrutura (campos, até 30) e cadastre/publique os registros (fornecedores, modelos, tribunais…).

• Por quê antes dos formulários: o campo Registro de base do formulário aponta para uma base existente e com registros publicados.
• Depois do primeiro registro só é possível acrescentar ou desativar campos — revise a estrutura antes.

Etapa 8 — Tipos de documento

Administração › Documentos › Tipos: chave, rótulo, formatos aceitos (MIME), tamanho máximo e Sensibilidade (Normal/Sensível).

• Por quê antes dos requisitos: cada item de um requisito aponta para um tipo.

Etapa 9 — Requisitos de documentos

Administração › Documentos › Requisitos: chave, rótulo, Prazo em horas, Máx. rodadas, Quem anexa e, para cada documento, tipo, obrigatório e Validadores em ordem (departamento e/ou cargo).

• Por quê antes do fluxo: o bloco Solicitação de documentos só aceita requisitos existentes; o editor bloqueia a publicação com requisito ausente ou desconhecido.

Etapa 10 — Formulários

Administração › Modelagem › Formulários: Novo formulário, campos, Preview, Publicar versão.

• Por quê antes do fluxo: o servidor recusa a publicação de um fluxo que cite formulário inexistente ou arquivado.
• A chave do campo é o nome da variável do processo. Combine as chaves com o que os gateways e regras vão ler.

Etapa 11 — Regras de negócio

Administração › Modelagem › Regras: entradas, saídas, política, linhas (com a linha “senão”), Testar e Publicar.

• Por quê antes do fluxo: o bloco Regra de negócio só aceita regras publicadas; saídas do tipo Cargo são conferidas contra os cargos existentes.

Etapa 12 — O fluxo

Administração › Modelagem › Fluxos › Novo fluxo (em branco, a partir de modelo do pacote, ou Importar .bpmn). Configure cada tarefa (formulário, grupo candidato, prazo), os blocos (documentos, regra, prazo, integração), papéis externos e marcos. Publicar no Camunda.

• O validador do editor confere tudo o que foi criado nas etapas anteriores. Erros bloqueiam; avisos pedem confirmação. Leia cada aviso.
• Lembre: alterar um formulário depois exige republicar o fluxo para valer em processos novos.

Etapa 13 — Ajustes do fluxo publicado

Na lista de fluxos: Configurar cartão (o que aparece no card da caixa de tarefas), Configurar métricas (campos como dimensão, medida ou período) e, em Documentos › Anexos permitidos, o que pode ser anexado fora das etapas.

Etapa 14 — Integrações e assistente (escopo Grupo)

Administração › Configurações: Integrações (assistente de 6 passos: chave de API exibida uma vez, webhook, teste), Domínios de imagem e Assistente de IA (provedor, modelo e chave do próprio cliente).

• Por quê depois do fluxo: a integração declara quais processos pode iniciar, e os blocos de envio citam a integração.

Etapa 15 — Usuários

Administração › Organização › Usuários › Convidar usuário: e-mail, cargo, departamento e unidade.

• Por quê por último: o convite dispara e-mail na hora. Convidar antes de os cargos estarem certos significa usuários entrando e não vendo suas tarefas — a pior primeira impressão possível.
• Comece pelos usuários-chave (homologação) e só convide todos perto do go-live.

Etapa 16 — Participantes externos (se houver)

Administração › Organização › Participantes externos: pré-cadastro opcional. O convite ao portal só sai quando a pessoa é vinculada a um processo.

Checklist de configuração

Use este checklist durante a fase 5. Ele fica salvo no seu navegador e pode ser copiado em Markdown para o documento de configuração.

O documento de configuração

Ao terminar, entregue ao cliente um documento que registre o que foi criado e com que chave. Ele é a memória do projeto: quando alguém perguntar daqui a um ano por que o cargo ANALISTA_TECNICO valida o parecer, a resposta está lá. Estrutura mínima:

# Documento de configuração — <Cliente> — <Processo>

## Organização
- Grupo: <nome> · Segmento: <segmento>
- Matrizes/filiais: <lista com CNPJ>

## Departamentos
| Nome | Uso |

## Cargos
| Chave | Nome | Nível | Escopo | Visibilidade | Permissões |

## Calendário
| Data | Nome | Unidade | Repete |

## Catálogos
- Bases de dados: <chave> — <campos>
- Tipos de documento: <chave> — <formatos/tamanho/sensibilidade>
- Requisitos: <chave> — <itens, quem anexa, validadores, prazo, rodadas>
- Formulários: <chave> — <versão> — <campos-chave>
- Regras: <chave> — <versão> — <entradas → saídas, política>

## Fluxo
- Chave: <CHAVE> · Versão publicada: vN · Data
- Tarefas: <nome> — <responsável> — <formulário> — <prazo>
- Decisões: <gateway> — <condição> — <padrão>

## Integrações
- <nome> — processos permitidos — webhook — responsável técnico do cliente

Há uma versão completa para copiar em Modelos e checklists.

Resumo

• Configure de baixo para cima: estrutura, catálogos, fluxo, conexões e, por último, pessoas.
• Unidades, departamentos e cargos vêm antes de tudo porque o resto os referencia.
• Calendário antes do go-live: prazos já calculados não são recalculados.
• Formulários, regras e requisitos precisam estar publicados antes do fluxo; o validador confere.
• Convide usuários só depois de os cargos estarem certos — primeiro os usuários-chave.
• Registre tudo no documento de configuração.