Aprovações perdidas no e-mail, arquivos chamados “final-agora-vai” e documentos aprovados que continuam na pasta errada: muitos problemas acontecem entre uma tarefa e outra. Um editor visual de fluxos documentais torna essas passagens claras. A equipe define qual evento inicia o processo, quais documentos entram nele, quem precisa agir e para onde o arquivo segue.
O Workflow Designer do Folderit funciona dentro do sistema de gestão de documentos, junto dos arquivos, das permissões e do histórico de versões. Este guia explica o modelo básico e apresenta duas configurações possíveis. Os exemplos são propostas ilustrativas de configuração, sem alegação de teste em ambiente real.
Revisão funcional em 10 de novembro de 2026, com base no artigo original em inglês de 29 de janeiro de 2026. Os nomes e parâmetros atuais foram conferidos na documentação indicada.
O que é um editor de fluxos documentais?
É uma ferramenta para desenhar processos repetitivos de documentos em uma área visual, conectando eventos, condições e ações. Em vez de depender da memória de alguém, de uma planilha ou de uma sequência extensa de mensagens, a equipe registra as regras que devem conduzir cada passagem.
A necessidade costuma começar pela aprovação. Mas o trabalho também trava antes e depois da decisão: encontrar a versão certa, solicitar a participação das pessoas responsáveis e guardar o resultado no local correto. Um editor de fluxos conecta essas atividades. A organização continua responsável por decidir quais regras fazem sentido e quem deve responder por elas.
Um modelo simples para planejar
Gatilho → Condições → Etapas → Resultados é uma boa estrutura para começar. Escreva o processo nessa ordem antes de desenhá-lo na ferramenta.
- Gatilho: o que aconteceu? Pode ser o envio de uma nova versão, a movimentação de um item, a alteração de metadados ou a inclusão de uma tag ou de um compartilhamento.
- Condições: quais itens devem participar? Delimite a pasta, o tipo de item, o nome ou os valores de metadados relevantes.
- Etapas: qual é a próxima ação? Aguardar, mover o item ou enviar uma tarefa formal para participantes definidos.
- Resultados: qual caminho seguir depois? Uma condição verdadeira e uma aprovação são resultados de naturezas diferentes.
Na etapa normal Condition, Success significa que a condição é verdadeira; Failure, que ela é falsa. Esse segundo caminho não representa uma rejeição humana. Já Request action tem saídas próprias de sucesso, falha e tempo limite.
Quatro problemas que justificam organizar o fluxo
Confusão entre versões
Alguém aprova uma versão antiga enquanto outra pessoa já envia uma revisão. Ou a versão correta é aprovada, mas uma cópia diferente é encaminhada. A decisão precisa corresponder à versão efetivamente analisada. Uma nova versão não recebe automaticamente a aprovação da anterior.
Falhas de encaminhamento
O documento está aprovado, mas continua em Rascunhos, na área pessoal de alguém ou no projeto errado. Uma regra de destino deixa claro onde o trabalho prossegue e reduz dúvidas sobre o status.
Compartilhamento sem visibilidade
Um link ou acesso novo a um conteúdo confidencial pode passar despercebido. Uma tarefa posterior de conferência ajuda a sinalizar o evento. Para decidir o que fazer, é necessário verificar o destinatário e as permissões efetivamente concedidas.
Falta de evidências
Quem analisou qual versão e quando? O histórico de versões, os detalhes das tarefas e os registros de auditoria ajudam a reconstruir o processo. Esses registros não garantem, por si só, conformidade legal: permissões, procedimentos e exigências aplicáveis também precisam ser avaliados.
Como montar o processo no Folderit
Abra Admin tools → Workflows e crie uma automação. Use um nome que descreva seu objetivo e confira o estado Enabled. Adicione pelo menos um Starting point, com o evento adequado e condições restritas. Um ponto de partida nomeado também pode ser iniciado manualmente pelo menu Workflow de um item.
Entre os eventos documentados estão File version added, Item moved, alteração de metadados, Tag added, Share added e Request responded. Escolha o evento que representa a mudança desejada. Uma resposta recebida não comprova que toda a aprovação foi concluída.
As condições incluem tipo, nome, localização, metadados e Requests completed. Diferencie a própria pasta dos itens dentro dela. Defina se o alcance inclui somente aquela pasta, todas as subpastas ou uma quantidade limitada de níveis. Sem essa decisão, uma regra correta pode gerar tarefas demais para a equipe.
As etapas documentadas são Condition, Delay, Move, Run automation, Send reminder, Wait for event e Request action. A captura antiga ainda usa Resolution para tarefas formais; o nome atual é Request action.
Essas etapas permitem verificar condições, esperar, mover itens, chamar outra automação salva e enviar solicitações. Elas não configuram sozinhas cálculos automáticos, classificação documental ou seleção automática de pessoas por departamento. Necessidades desse tipo exigem regras verificadas ou uma integração específica.
Conectar o ciclo de vida às decisões
A estrutura Rascunho → Em análise → Aprovado → Arquivado pode transformar as pastas em uma referência de status. Isso só funciona com permissões, encaminhamento e decisões coerentes com cada etapa. Mover para “Arquivado” não cria uma regra legal de retenção nem promete exclusão futura.
Em Request action, defina usuários ou grupos e execução paralela ou sequencial. Escolha se todos os destinatários, uma quantidade específica ou um percentual precisam concluir a tarefa. Configure também o limite de rejeições. Receber respostas e alcançar um resultado positivo não são a mesma coisa.
As opções de método incluem Approval, Acknowledgement, Folderit eSign, DocuSign, eID e Fill fields. Uma etapa de revisão pode usar um método personalizado; não suponha que “Review” seja uma opção universal em todas as contas. Confira a disponibilidade e a configuração dos métodos de assinatura.
Due By informa uma data de entrega. O parâmetro explícito Timeout determina o tempo limite; 0 significa ausência desse limite. A data informada passar não garante um encaminhamento para escalonamento. Combine também quem assume um caso sem resposta.
Exemplo 1: aprovação de contratos com destino definido
Imagine novas versões de contratos na pasta “Contratos/Análise”. Preserve duas fases de negócio: obter a aprovação e encaminhar segundo o resultado. Um único fluxo visual pode organizar as duas:
- Use File version added, com condição de arquivo e localização limitada à área de análise.
- Adicione Request action com Approval. Indique pessoas do jurídico, do financeiro e da gestão. Nesta configuração, os participantes são escolhidos explicitamente; os metadados não selecionam essas pessoas automaticamente.
- Exija, por exemplo, aprovação dos três e configure falha após uma rejeição. Verifique as regras de conclusão e rejeição em conjunto.
- Conecte Success → Move a “Aprovado”, Failure → Move a “Ajustes” e Timeout → Move a “Escalonamento”.
No último caso, uma pessoa responsável avalia a próxima providência. Também é possível separar o encaminhamento em outra automação, desde que as condições comprovem a conclusão e o resultado correto. Não use somente Request responded: uma única resposta pode disparar esse evento.
Teste uma nova versão durante uma solicitação pendente. Evite solicitações duplicadas e defina o tratamento da análise anterior. A nova versão precisa da decisão prevista para ela; não basta que a versão anterior tenha sido aprovada.
Exemplo 2: conferir compartilhamentos em pastas confidenciais
Outro cenário usa Share added, restrito ao local e tipo de item desejados. O fluxo cria uma tarefa para uma pessoa responsável por segurança. Use um método personalizado de revisão, se estiver configurado, ou Approval como alternativa.
Essa pessoa examina o destinatário, o link e as permissões reais. A automação reage depois da criação do compartilhamento. Ela não impede previamente acessos externos, não classifica automaticamente destinatários externos e não revoga permissões. Mover o arquivo também não comprova que o link deixou de funcionar. Qualquer correção deve ser aplicada aos controles reais de compartilhamento e acesso.
Inclua nos testes um compartilhamento permitido e uma ação fora da pasta monitorada. Assim, a equipe verifica se a análise está limitada ao alcance combinado.
Três erros comuns
- Abranger tudo: comece com uma pasta, um tipo de item e um evento necessário. Excesso de solicitações reduz a atenção.
- Colocar toda a operação em uma regra: diferencie a solicitação e o encaminhamento após o resultado. Ramificações claras podem bastar; automações separadas exigem condições corretas de conclusão.
- Ignorar a estrutura de destino: defina pastas e permissões antes de ativar. Uma decisão correta não resolve um arquivo difícil de encontrar.
O que testar antes de usar
Use arquivos de demonstração identificados e avise os participantes. Teste uma nova versão dentro do alcance, um item fora dele, aprovação, rejeição, ausência de resposta com timeout, nova versão durante uma análise e indisponibilidade de um revisor. Confira tarefa, versão, resultado e pasta de destino em cada caso. Defina uma pessoa responsável pelo escalonamento.
Perguntas úteis para começar
O editor serve apenas para aprovações?
Não. Encaminhamento, ciclo de vida e reações específicas a alterações também fazem parte do uso. Procure a passagem que hoje causa atraso ou erro.
É necessário conhecimento técnico?
O primeiro requisito é combinar responsabilidades e regras. A área visual facilita a construção, mas não substitui a configuração cuidadosa e os testes dos resultados.
Qual processo escolher primeiro?
Escolha um caso recorrente: contratos, confirmação de leitura de políticas, organização após aprovação ou conferência de compartilhamentos. Descreva-o como gatilho, condições, etapas e resultados.
Veja o guia do Workflow Designer para os ajustes atuais e a visão geral dos fluxos documentais para conhecer os métodos. Antes de configurar, confira os recursos do plano atual e as opções de assinatura da sua conta.
