Como montar um fluxo de aprovação de documentos com funções de equipe no Chaindoc

Um fluxo de aprovação de documentos é o caminho que um contrato percorre do rascunho até a assinatura: quem pode abri-lo, quem precisa aprová-lo, em que ordem e que registro fica. No Chaindoc, esse caminho se apoia em dois ajustes. As funções definem quem vê e edita um documento dentro da sua equipe. No plano Business, uma rota de aprovação fixa a ordem em que se aprova e se assina. Todo o resto, do primeiro convite à trilha de auditoria, depende desses dois ajustes. Este guia mostra como configurá-los com a gestão de equipes do Chaindoc, o que cada plano inclui e onde ferramentas maiores, como o SharePoint, vão mais longe.

A maioria dos problemas de um fluxo de aprovação de documentos começa antes da aprovação. Um rascunho cai na pasta compartilhada, o link circula e, quando o jurídico abre, cinco pessoas já leram e duas já editaram.

Em muitas ferramentas, esse é o padrão. No Google Drive, quem você define como editor pode compartilhar o arquivo e alterar as permissões dele, a menos que o proprietário desative isso, e o acesso dado a uma pasta é herdado por todos os arquivos dentro dela (Ajuda do Google Drive). Ótimo para uma apresentação. Nem tanto para um contrato com fornecedor que traz as suas margens.

O controle de acesso a documentos no Chaindoc funciona em dois níveis, com um terceiro para desenvolvedores:

• Espaço de trabalho. Cada usuário tem um espaço pessoal, e os planos de equipe acrescentam um compartilhado. Os dois não se misturam: um rascunho guardado no seu espaço pessoal fica fora da vista do time. Os contratos da equipe pertencem ao espaço compartilhado.
• Função. Dentro do espaço compartilhado, o que alguém pode fazer com um documento (ver, editar, aprovar, assinar) segue a função que ela ou ele tem, e não um link que alguém encaminhou.
• Pela API do Chaindoc, que exige o plano Business, cada documento tem um tipo de acesso: privado (private), público (public) ou restrito (restricted). Em um documento restrito, as pessoas que podem abri-lo constam por e-mail, cada uma com um nível como read.

Nossa regra prática: entregue o rascunho a quem precisa lê-lo antes da aprovação, não a todos que teriam curiosidade. Dá para ampliar o acesso depois da assinatura. Tirar o acesso depois que alguém baixou o arquivo, não. Se o contrato tem dados pessoais, isso vai além da boa educação: mais abaixo estão os artigos 6º, 46 e 47 da LGPD.

Um limite honesto: os arquivos trafegam por TLS, mas não há criptografia de ponta a ponta, então os servidores do Chaindoc conseguem ler o que processam. Dentro da sua empresa, as funções fazem o contrato ficar diante das pessoas certas.

O controle de acesso baseado em funções (RBAC) liga permissões a uma função e depois dá a função às pessoas. O glossário do NIST o descreve como controle de acesso baseado nas funções dos usuários, sendo a função um conjunto de autorizações de acesso. No dia a dia, é a gestão de permissões: quem pode fazer o quê em cada documento. Quando alguém muda de cargo, você troca uma função e o acesso acompanha.

A gestão de equipes do Chaindoc traz quatro funções prontas, a metade de acesso de qualquer fluxo de aprovação de documentos:

• Owner: todos os direitos sobre os documentos e os controles de administração da equipe. Em geral quem fundou a empresa ou quem cuida do orçamento.
• Admin: gerencia usuários e acompanha os fluxos. Normalmente a pessoa de operações ou de administração.
• Member: lê e edita dentro das permissões que a função permite. É onde fica a maior parte do time.
• Accounter: vê o lado financeiro e analítico dos documentos. Pense em quem cuida da contabilidade ou no contador externo.

Cada função pronta pode ser ajustada, e você cria quantas funções próprias precisar, com qualquer combinação de permissões. Vemos duas com frequência: uma função de revisão jurídica, que vê e aprova contratos mas não os envia, e uma função comercial, que redige e envia mas nunca aprova. As mudanças feitas na aba Roles valem na hora para todos os fluxos ativos.

Quatro funções bastam? Para uma equipe de cinco a cinquenta pessoas, quase sempre. Os pacotes corporativos oferecem listas mais longas. Na nossa experiência, equipes pequenas raramente precisam delas, e cada função a mais é uma que alguém terá de revisar todo trimestre.

O princípio dos quatro olhos diz que duas pessoas precisam participar antes que algo importante valha: um pagamento, a alteração de um registro, um contrato. Auditores falam de forma mais ampla em segregação de funções (separation of duties, em inglês). A definição do NIST é direta: nenhum usuário deveria receber privilégios suficientes para usar mal o sistema sozinho (glossário do NIST). A mesma entrada separa dois casos. A separação estática impede que funções incompatíveis cheguem à mesma pessoa. A dinâmica age no momento da ação, e a regra das duas pessoas é o exemplo clássico.

No Brasil, a ideia aparece na estrutura societária e no controle interno. Na Lei das S.A., o estatuto define as atribuições e os poderes de cada diretor (art. 143, IV), e o conselho de administração pode ter de se manifestar previamente sobre atos ou contratos quando o estatuto assim exigir (art. 142, VI). As companhias abertas ainda descrevem seus controles internos no formulário de referência exigido pela CVM (Resolução CVM 80/2022, art. 25 e Anexo C, item 5). Em uma empresa menor, o paralelo é o diretor estatutário que só assina depois que o jurídico aprova, ou a procuração com limites de poderes. Um fluxo de aprovação de documentos leva essa regra para o próprio documento, em vez de deixá-la na cabeça da diretoria.

Para uma equipe que lida com contratos, isso vira três hábitos:

1. 1.
   Quem redige o contrato não é quem o aprova.
2. 2.
   Contratos grandes levam mais de um nome entre o rascunho e a assinatura.
3. 3.
   O financeiro vê quanto vale o contrato, mas não consegue reescrevê-lo.

Nada disso exige software especial. Exige alguém que decida e uma ferramenta que lembre da decisão.

Menor privilégio, em linguagem simples

O NIST (SP 800-12) define menor privilégio como limitar o acesso de cada usuário ao mínimo necessário para suas tarefas. No Chaindoc, isso quer dizer que Member é o padrão, Admin a exceção e Owner coisa de uma ou duas pessoas. Para ser sincero, a maioria das equipes pequenas faz o contrário: as cinco primeiras pessoas viram Admin porque foi mais rápido, e ninguém revisa depois.

Alçada de aprovação e rota de aprovação

Em muitas empresas, a alçada define até que valor cada pessoa pode aprovar: o gerente até certo ponto, o diretor acima dele, o conselho nos contratos maiores. É a regra que dá corpo aos quatro olhos. As funções cobrem a metade estática; a rota de aprovação, a dinâmica. Um pedido de assinatura comum no Chaindoc convida todos os destinatários ao mesmo tempo, e quem abre primeiro assina primeiro. No plano Business, uma rota de aprovação fixa a sequência: a próxima pessoa só recebe o documento depois que a anterior agiu. Primeiro o jurídico, depois o financeiro, depois a diretoria. A rota fixa a ordem, não valores: o Chaindoc não aplica a alçada sozinho. Se a sua política diz que contratos acima de certo valor passam pelo diretor financeiro, registre a regra por escrito e deixe quem envia escolher a rota correspondente.

As funções e o espaço compartilhado, o lado de acesso de um fluxo de aprovação de documentos, começam no plano Team. A ordem fixa exige Business, assim como o acesso à API. Os números abaixo vêm dos planos do Chaindoc como estavam publicados em 20 de setembro de 2026; a página de preços traz os atuais. Se você compara software de fluxo de aprovação pelo preço, conte também os lugares: cada membro extra custa 19 € por mês nos dois planos de equipe.

Falta um número de propósito. A cota mensal de assinaturas do plano Team mostra um valor no cartão do plano e outro na configuração dele. Preferimos remeter à página de preços a imprimir o errado.

Um fluxo de aprovação de documentos só ajuda se for possível mostrar depois quem aprovou o quê. O Chaindoc guarda a prova em dois lugares, e cada um faz um trabalho diferente.

A trilha de auditoria é o registro de eventos da própria aplicação para o documento. As entradas são encadeadas por hashes, então uma entrada que falta ou foi alterada quebra a cadeia. Você pode exportá-la em PDF, e existe um relatório de verificação em PDF, separado, para o arquivo assinado. Se você usou uma verificação de identidade, o resultado também fica na trilha.

A blockchain registra dois momentos: o hash da versão na publicação e a prova de cada signatário quando a assinatura termina. É contra esse hash que uma verificação posterior confere o arquivo.

Na prática, a maioria das divergências nunca chega à cadeia. Elas se resolvem com um registro legível de quem fez o quê, e por isso a exportação em PDF pesa mais no dia a dia. O que um auditor ou um tribunal costuma pedir está em como o registro de uma assinatura eletrônica resiste a uma auditoria.

Antes de comprar software de aprovação de documentos, veja o que você já tem. Muitas equipes já rodam um fluxo de aprovação em uma ferramenta que possuem, ou acham que rodam. Veja o que cobrem as três mais comuns.

SharePoint e Power Automate

Um fluxo de aprovação do SharePoint costuma ser um fluxo do Power Automate. O tutorial da Microsoft o constrói em torno da ação "Aprovações - Iniciar e aguardar uma aprovação", e os aprovadores respondem pela caixa de entrada, pelo centro de aprovações ou pelo aplicativo móvel (Microsoft Learn). As aprovações sequenciais e as paralelas têm cada uma o seu guia, e convidados de fora da empresa podem aprovar pelo Microsoft Entra. O porém: o fluxo é você quem constrói e mantém, e o tutorial diz com todas as letras que a segurança está fora do seu escopo.

DocuSign

Quem pesquisa funções e permissões do DocuSign costuma chegar aos três perfis de permissão padrão: DS Admin, DS Sender e DS Viewer. O DocuSign também descreve, na sua central de suporte, um fluxo de aprovação interno. Um fluxo de aprovação do DocuSign é, portanto, uma tarefa de configuração em uma conta que talvez você já pague.

Google Drive

As permissões do Google Drive para compartilhar são três funções: leitor, comentador e editor. Elas decidem quem pode abrir, comentar e alterar um arquivo. Quem aprova e quem assina é outra pergunta, respondida em outro lugar.

Onde eles estão à frente: o Power Automate consegue condicionar uma aprovação a quase qualquer critério e rodá-la entre SharePoint, Dynamics 365 ou Salesforce, e os aprovadores do Microsoft 365 usam as contas corporativas com as quais já entram. O Chaindoc não tem login único nem provisionamento SCIM. Entra-se com senha ou com uma conta Google, GitHub ou Apple, e quem sai da empresa você remove à mão. O que o Chaindoc reúne em um só lugar são o acesso, a ordem, a assinatura e o registro do mesmo contrato.

Não. No Brasil, a MP 2.200-2/2001 não impede outros meios de comprovar autoria e integridade de documentos eletrônicos, inclusive certificados não emitidos pela ICP-Brasil, desde que as partes os admitam (art. 10, § 2º), e a Lei 14.063/2020 classifica as assinaturas eletrônicas em simples, avançada e qualificada (art. 4º). Na União Europeia, o artigo 25(1) do eIDAS impede que se negue efeito jurídico a uma assinatura eletrônica em juízo só porque ela é eletrônica. O seu fluxo de aprovação de documentos é governança, não parte da formação do contrato. O que ele muda é a sua posição se alguém alegar depois que o contrato foi assinado sem poderes.

O acesso entra na lei por outro caminho. A LGPD tem a segurança entre os seus princípios (art. 6º, VII), exige medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados (art. 46) e estende o dever de garantir a segurança da informação a qualquer pessoa que intervenha no tratamento, mesmo depois do término (art. 47). Um link que qualquer um abre combina mal com isso. Mas o controle de acesso vale nos dois sentidos: afaste quem não deve ver o contrato, sem deixar de fora quem precisa consultá-lo. Para os prazos, veja por quanto tempo guardar contratos assinados.

Em Portugal, o Decreto-Lei n.º 12/2021 assegura a execução do eIDAS no direito interno, e o RGPD (artigos 25.º e 32.º) faz o papel da LGPD. Isto é informação geral, não aconselhamento jurídico para a sua empresa.

As mesmas cinco falhas aparecem de novo e de novo:

• Todo mundo é Admin. Aconteceu na configuração e ficou assim. Reduza para uma ou duas pessoas.
• O fluxo de aprovação de contratos mora na cabeça de alguém. Quando essa pessoa está fora, os contratos param ou saem sem aprovação. Escreva as rotas e dê a elas o nome do tipo de contrato.
• As aprovações acontecem por e-mail. Um "pode seguir" numa conversa não está na trilha de auditoria, e seis meses depois ninguém acha.
• Quem saiu continua com acesso. Sem provisionamento automático, o desligamento precisa de uma linha na lista de tarefas: remover do Chaindoc.
• A versão aprovada não é a assinada. Se alguém edita depois da aprovação, é preciso publicar uma nova versão e passar de novo pela rota. O hash da versão antiga já está na blockchain, que é exatamente o que você quer quando perguntam o que mudou.

Resolva esses cinco e um fluxo de aprovação de documentos no Chaindoc praticamente se cuida sozinho. As funções mantêm os rascunhos privados, a rota mantém a ordem e o registro responde às perguntas depois.