Aprovações dispersas por correio eletrónico, ficheiros chamados «final-definitivo» e documentos aprovados que permanecem na pasta errada: as dificuldades surgem muitas vezes entre tarefas. Um editor visual de fluxos documentais torna essas passagens explícitas. A equipa decide que acontecimento inicia o processo, que documentos entram nele, quem intervém e para onde segue o ficheiro.
O Workflow Designer do Folderit funciona dentro do sistema de gestão documental, junto dos ficheiros, das permissões e do histórico de versões. Este guia explica o modelo de funcionamento e apresenta duas configurações possíveis. Os exemplos são propostas ilustrativas, sem alegação de testes em produção.
Revisão funcional de 10 de novembro de 2026, com base no artigo inglês de 29 de janeiro de 2026. As designações e os parâmetros atuais foram considerados a partir da documentação indicada.
O que é um editor de fluxos documentais?
É uma ferramenta que permite representar processos documentais repetidos numa área visual, ligando acontecimentos, condições e ações. A passagem à etapa seguinte passa a seguir regras definidas, em vez de depender da memória de um colega, de uma folha de cálculo ou de uma longa troca de mensagens.
A aprovação costuma ser a primeira necessidade. Mas também se perde tempo a localizar a versão certa, a envolver os responsáveis e a arquivar o resultado no local adequado. Um editor de fluxos liga estas atividades. Cabe à organização definir regras que correspondam ao seu trabalho e atribuir responsabilidades claras.
O modelo: evento, condições, etapas e resultados
Evento de início → Condições → Etapas → Resultados é uma estrutura útil para planear. Comece por escrever o processo nesta ordem, antes de o desenhar na ferramenta.
- Evento de início: o que aconteceu? Por exemplo, uma nova versão, a deslocação de um elemento, uma alteração de metadados ou a adição de uma etiqueta ou partilha.
- Condições: quais os elementos abrangidos? Delimite a pasta, o tipo de elemento, o nome ou os metadados relevantes.
- Etapas: o que deve acontecer a seguir? Pode ser uma espera, uma deslocação ou um pedido de ação dirigido a pessoas identificadas.
- Resultados: que percurso corresponde ao resultado observado? Uma condição verdadeira não equivale à aprovação de um documento.
Numa etapa Condition normal, Success significa que a condição é verdadeira e Failure que é falsa. Este último resultado não representa uma rejeição por um participante. A etapa Request action tem saídas próprias para sucesso, falha e tempo limite.
Quatro problemas que um fluxo ajuda a resolver
Confusão de versões
Uma pessoa aprova uma versão antiga enquanto outra já carrega uma revisão. Ou aprova-se o ficheiro correto, mas envia-se outra cópia. A decisão deve corresponder à versão efetivamente analisada. Uma nova versão não herda automaticamente a aprovação anterior.
Falhas no encaminhamento
O documento foi aprovado, mas continua em Rascunhos, numa área pessoal ou na pasta de outro projeto. Uma regra de destino clarifica onde o processo prossegue e reduz pedidos de esclarecimento sobre o estado do documento.
Partilhas pouco visíveis
Um novo acesso ou uma ligação para um conteúdo confidencial pode passar despercebido. Um pedido posterior de verificação dá visibilidade ao acontecimento. Para decidir a medida adequada, é necessário examinar o destinatário e as permissões reais.
Falta de rastreabilidade
Quem analisou que versão, e quando decidiu? O histórico de versões, os detalhes das tarefas e os registos de auditoria ajudam a reconstruir o processo. Não garantem, por si só, conformidade legal: também é preciso avaliar os direitos de acesso, os procedimentos e as exigências aplicáveis.
Como configurar o fluxo no Folderit
Abra Admin tools → Workflows e crie uma automatização. Atribua-lhe um nome compreensível e verifique o estado Enabled. Adicione pelo menos um Starting point, com o evento adequado e condições restritas. Um ponto de início com nome também pode ser executado manualmente no menu Workflow de um elemento.
Os eventos documentados incluem File version added, Item moved, alteração de metadados, Tag added, Share added e Request responded. Escolha aquele que corresponde à passagem pretendida. A receção de uma resposta não comprova a conclusão de toda a aprovação.
As condições incluem tipo, nome, localização, metadados e Requests completed. Distinga a própria pasta dos elementos que contém. Decida se o âmbito inclui apenas essa pasta, todas as subpastas ou um número limitado de níveis. Uma regra demasiado abrangente pode gerar pedidos que distraem a equipa do trabalho necessário.
As etapas documentadas são Condition, Delay, Move, Run automation, Send reminder, Wait for event e Request action. A imagem antiga ainda utiliza Resolution para tarefas formais; a designação atual é Request action.
Estas etapas permitem verificar condições, aguardar, deslocar elementos, iniciar outra automatização guardada e enviar pedidos. Não configuram, por si, cálculos automáticos, classificação documental ou seleção automática de pessoas por departamento. Esses requisitos precisam de regras verificadas ou de uma integração específica.
Ligar o ciclo de vida às decisões
A estrutura Rascunho → Em análise → Aprovado → Arquivado pode tornar as pastas numa referência de estado. Só é útil com permissões, encaminhamento e decisões coerentes com essas etapas. Deslocar para «Arquivado» não define, por si, uma obrigação legal de conservação nem uma eliminação futura.
Em Request action, escolha utilizadores ou grupos e um tratamento paralelo ou sequencial. Determine se todos os destinatários, um número específico ou uma percentagem precisam de concluir a tarefa. Configure também o limiar de rejeição. A existência de respostas não equivale necessariamente ao sucesso do pedido.
Os métodos incluem Approval, Acknowledgement, Folderit eSign, DocuSign, eID e Fill fields. Uma análise pode usar um método personalizado; não pressuponha que «Review» está disponível de forma idêntica em todas as contas. Confirme a disponibilidade e a configuração dos métodos de assinatura.
Due By corresponde a uma data informativa. O parâmetro explícito Timeout define o tempo limite; o valor 0 significa que não há timeout. A passagem da data apresentada não garante um encaminhamento para análise adicional. Acorde quem assume um processo sem resposta.
Exemplo 1: aprovar contratos e encaminhar o resultado
Imagine novas versões na pasta «Contratos/Análise». Mantenha duas fases de negócio: obter a aprovação e encaminhar segundo o resultado. Um único fluxo visual permite relacioná-las:
- Configure File version added, com uma condição de ficheiro e localização limitada à pasta de análise.
- Adicione Request action com Approval. Identifique pessoas do departamento jurídico, financeiro e da direção. Nesta configuração, são escolhidas expressamente, não selecionadas automaticamente pelos metadados.
- Exija, por exemplo, a aprovação das três pessoas e configure falha após uma rejeição. Verifique conjuntamente as regras de conclusão e rejeição.
- Ligue Success → Move a «Aprovado», Failure → Move a «A corrigir» e Timeout → Move a «Exceções».
Neste último caso, um responsável avalia a próxima ação. Também pode separar o encaminhamento numa automatização posterior, desde que as condições confirmem a conclusão e o resultado. Não use apenas Request responded: este evento pode corresponder a uma única resposta.
Teste uma nova versão durante um pedido pendente. Evite pedidos duplicados e defina o tratamento da análise anterior. A nova versão deve receber a decisão que lhe corresponde; a aprovação de uma versão anterior não basta.
Exemplo 2: verificar partilhas numa área confidencial
Outro cenário utiliza Share added, limitado à localização e ao tipo de elemento pretendidos. O fluxo cria um pedido para um responsável de segurança identificado. Use um método personalizado de análise, se estiver configurado, ou Approval.
O responsável examina o destinatário, a ligação e as permissões efetivas. A automatização reage depois da criação da partilha. Não é um bloqueio preventivo de acessos externos, uma classificação automática de destinatários externos ou uma revogação automática. Deslocar o ficheiro também não comprova a desativação da ligação. As correções devem ser feitas nos controlos reais de partilha e acesso.
Inclua nos testes uma partilha permitida e um acontecimento fora da pasta abrangida. Assim confirma se o controlo respeita o âmbito acordado.
Três erros comuns
- Abranger demasiado: comece com uma pasta, um tipo de elemento e um evento necessário. O excesso de pedidos reduz a atenção.
- Fazer tudo na mesma regra: distinga o pedido e o encaminhamento após a decisão. Percursos claros podem bastar; automatizações separadas exigem condições de conclusão rigorosas.
- Ignorar o destino: defina pastas e permissões antes de ativar. Uma aprovação correta não resolve um arquivo difícil de localizar.
Verificar antes de utilizar
Utilize ficheiros de demonstração identificados e informe os participantes. Teste uma nova versão abrangida, um elemento excluído, aprovação, rejeição, falta de resposta com timeout, nova versão durante a análise e indisponibilidade de um revisor. Confira tarefa, versão, resultado e pasta final. Acorde quem é o responsável humano pelo tratamento das exceções.
Perguntas para começar
O editor serve apenas para aprovações?
Não. O encaminhamento, o ciclo de vida e as reações específicas a alterações também são aplicações úteis. Procure primeiro a passagem que causa atrasos ou erros.
É preciso ter conhecimentos técnicos?
É sobretudo necessário acordar responsabilidades e regras. A representação visual facilita a construção, mas a configuração cuidadosa e os testes continuam a ser essenciais.
Qual deve ser o primeiro processo?
Escolha um caso recorrente: contratos, confirmação de leitura de políticas, arquivo após decisão ou verificação de partilhas. Descreva-o como evento, condições, etapas e resultados.
Consulte o guia do Workflow Designer para os parâmetros atuais e a apresentação dos fluxos documentais para os métodos. Antes de configurar, verifique as funcionalidades do plano atual e as opções de assinatura da sua conta.
