Um fluxo de trabalho transforma uma decisão de governança em um caso rastreável, com tarefas, decisões, evidências e notificações. Ele parte de um objeto ou assunto específico, segue as etapas definidas pela empresa e não substitui a taxonomia nem os vínculos registrados.
O GovFrame permite configurar fluxos de trabalho por tipo e quantidade de etapas. Um caso pode manter o contexto de Domínio ou Subdomínio de forma direta, ou derivá-lo do objeto afetado. Por isso, a autorização não depende apenas da participação em uma tarefa: a empresa, o módulo, a capacidade e o escopo aplicável continuam sendo verificados.
Antes de começar
- Papel: o Administrador pode gerenciar a operação e os parâmetros permitidos para a empresa. Um Responsável pelos dados atende decisões que exigem aprovação dentro de seu escopo; um Curador de dados trabalha em definições e tarefas nos Domínios ou Subdomínios atribuídos. Um Usuário participa somente das atividades para as quais tem autorização.
- Módulo: Fluxos de trabalho de governança deve estar habilitado para a empresa. Se for desativado, deixa de ser operável tanto pela interface quanto pelos procedimentos da aplicação; os dados existentes não são excluídos automaticamente.
- Pré-requisitos: identifique o objeto ou assunto que motiva o caso, seu contexto taxonômico, quando houver, e os responsáveis que podem participar. Se o fluxo precisar de um papel de fluxo de trabalho ou de uma responsabilidade de governança, a empresa deve tê-los definido e atribuído de maneira compatível com o escopo.
Antes de começar, diferencie dois níveis. O modelo descreve como um tipo de gestão será organizado; o caso é a instância específica acompanhada para um objeto ou uma solicitação. Essa distinção evita tratar uma tarefa isolada como se fosse um novo processo de governança.
Percurso recomendado
- Delimite o propósito e o contexto. Explique o que precisa ser resolvido, qual é o objeto afetado e a que Domínio ou Subdomínio ele pertence. Quando o contexto vier do objeto, revise-o antes de atribuir o trabalho: uma relação herdada serve para navegação e autorização, mas não altera o nível original do objeto.
- Defina o percurso funcional do modelo. Configure o tipo de fluxo de trabalho e a quantidade de etapas necessária para o processo da empresa. Em cada etapa, estabeleça qual responsabilidade deve participar e qual decisão ou evidência é esperada. Este é um percurso funcional: a documentação atual não publica um catálogo fixo de tipos, nomes de etapas, estados ou regras universais de atribuição.
- Abra e encaminhe o caso. Vincule o caso ao objeto de governança correspondente e atribua tarefas a pessoas com capacidade e escopo adequados. As notificações não substituem a revisão da tarefa e de seu contexto.
- Registre o trabalho verificável. Mantenha no caso a decisão tomada e as evidências disponíveis. Se o assunto depender de uma Regra de qualidade, primeiro confirme que a regra tem um campo físico associado e um dialeto configurado antes de esperar SQL; o fluxo de trabalho não gera nem executa SQL por si só.
- Conclua o acompanhamento com rastreabilidade. Revise as tarefas pendentes, as decisões e as evidências vinculadas ao mesmo caso. Para analisar o impacto do objeto antes de decidir, use o mapa de relações e siga somente os vínculos registrados, não as dependências inferidas pelo nome ou pelo compartilhamento de Domínio.
Exemplo sintético. A equipe detecta que a definição de um atributo de Clientes precisa ser revisada. É criado um caso associado ao atributo; um Curador prepara a proposta e as evidências de contexto, e o Responsável pelos dados competente toma a decisão dentro de seu escopo. O resultado fica vinculado ao caso, sem afirmar que exista uma etapa, estado ou formulário padrão para todas as empresas.
Resultado esperado
Ao final, deve haver rastreabilidade clara entre o assunto tratado, o objeto de governança, quando aplicável, as tarefas atribuídas, as intervenções, a decisão e suas evidências. O caso mantém o contexto necessário para que a empresa acompanhe o trabalho e para que o backend aplique as restrições de empresa, módulo, papel e escopo.
Um fluxo de trabalho bem operado deixa claro quem fez o quê, sobre qual objeto e com qual fundamento, sem criar um catálogo independente de Riscos ou Controles. No modelo atual, um controle pode ser representado por uma Regra de qualidade, uma Política ou Procedimento, uma aprovação, uma tarefa ou uma certificação; cada um mantém seu próprio objeto e relacionamento.
Limites do comportamento atual
- Os fluxos de trabalho são configuráveis, mas este guia não pressupõe estados, transições, SLAs, formulários ou sequências de telas que não estejam documentados para a empresa.
- A possibilidade de visualizar um objeto não concede automaticamente permissão para editá-lo, aprová-lo ou atribuir trabalho. As verificações são feitas no backend.
- Um módulo desativado bloqueia a operação, mas não exclui por si só casos, tarefas ou evidências existentes.
- As tarefas programadas de outras áreas, como sincronização de metadados ou backups, dependem de sua configuração. Um caso de fluxo de trabalho não deve ser interpretado como prova de que um job de produção foi executado.