Este guia explica como introduzir requisitos de aprovação num workflow de cada vez. O sistema foi concebido para uma adoção gradual: a sua Organização começa de forma ágil, com o Proprietário a poder fazer tudo sozinho, e vai ajustando cada workflow quando estiver pronto, podendo terminar, se assim o desejar, com uma configuração em que nenhuma pessoa, por si só, possa movimentar fundos ou alterar as regras.
Para conhecer o funcionamento das políticas, consulte Políticas, aprovações e governação. Para conhecer o modelo de acesso, consulte Funções, perfis e permissões.
O nível Execute e a definição «Exigir sempre aprovação» combinam-se em duas posturas:
Diferentes workflows podem ter posturas diferentes. Uma configuração comum: aprovações para todos no Pedido de Levantamento, via rápida no Pedido de Transferência (os fundos permanecem dentro da Organização) e aprovações em Gerir Políticas para proteger as próprias regras.
Os primeiros três passos são reversíveis. O bloqueio é o compromisso.
Passo 1 - Arranque
O Proprietário começa com o perfil de Administrador e a função de Acesso total definidos pelo sistema: Executar em todos os fluxos de trabalho; todas as permissões em todas as Contas. A política de cada fluxo de trabalho começa em Aberto. Enquanto Organização de utilizador único, opera exatamente como antes: nada aguarda aprovação, pois não há ninguém para aprovar.
Passo 2 - Configuração
Configure o processo de aprovação para um fluxo de trabalho — normalmente o Pedido de Levantamento em primeiro lugar — enquanto «Exigir sempre aprovação» permanece DESATIVADO:
Apenas os Membros que aceitaram o convite e concluíram a verificação são contabilizados para efeitos de aprovação. Um Membro convidado não é contabilizado enquanto ambos os passos não estiverem concluídos, mesmo que já apareça na lista da equipa.
Ainda nada está em vigor. Mantém o Execute e continua a trabalhar normalmente enquanto tudo é configurado.
Passo 3 - Validar
Ative «Always require approval» no fluxo de trabalho pretendido. Todos os pedidos, incluindo os seus, entram agora em fila. Verifique com pedidos em direto:
Esta é a janela segura: a governação está em vigor, mas a política ainda não está bloqueada, pelo que pode desativar a definição, ajustar e voltar a tentar quantas vezes forem necessárias. Decida se a configuração final deve manter «Always require approval» ativo ou desativado antes de bloquear a política.
Passo 4 - Bloquear
Bloqueie a política. O bloqueio é em si um pedido de Gerir Políticas: se Gerir Políticas já exigir aprovação, o bloqueio só entra em vigor após outro Membro o aprovar. A partir deste momento:
O bloqueio elimina a capacidade de qualquer pessoa de enfraquecer a governação neste fluxo de trabalho. Alterações futuras, incluindo o desbloqueio, dependem da disponibilidade de um aprovador independente em Gerir Políticas. Tenha em conta a cobertura de aprovadores quando os Membros mudam de função ou saem.
Passo 5 – Repetir
Todos os outros fluxos de trabalho mantêm a configuração atual até regressar ao Passo 2 para cada um. Qualquer combinação de fluxos de trabalho com e sem governação é um estado estável válido; a progressão é uma recomendação, não uma exigência.
O passo final – bloquear o próprio Gerir Políticas
Gerir Políticas tem a sua própria política e o seu próprio bloqueio. Bloqueá-lo é o estado final da implementação: a partir daí, qualquer alteração a regras na Organização – configurações de políticas, bloqueios e desbloqueios, em todos os fluxos de trabalho – requer aprovação independente, e ninguém pode enfraquecer a governação através do produto.
Execute este passo por último, depois de configurar e bloquear todos os fluxos de trabalho que pretende governar. Confirme primeiro que um pedido de Gerir Políticas ainda pode ser iniciado e aprovado sem a sua intervenção: alguém que o possa iniciar, mais tantos outros Membros com Aprovar em Gerir Políticas quantos esse fluxo de trabalho exigir, todos verificados e ativos. As políticas bloqueadas só podem ser alteradas enquanto esse percurso existir, e o sistema não o verifica por si. Consulte Políticas, aprovações e governação para saber como este bloqueio funciona.
A CFO pretende concluir os seus próprios levantamentos de imediato, enquanto todos os levantamentos dos gestores de fundos passam pela sua revisão.
Perfis de fluxo de trabalho:
Membro | Perfil | Níveis de Pedido de Levantamento |
|---|---|---|
CFO | Personalizado «CFO» | Ver, Iniciar, Aprovar, Executar |
Gestor de Fundos A | Iniciador (definido pelo sistema) | Ver, Iniciar |
Gestor de Fundos B | Iniciador (definido pelo sistema) | Ver, Iniciar |
Os três têm uma Função de Conta que concede o nível Levantar nas contas operacionais. Os níveis neste exemplo dizem respeito apenas ao Withdrawal Request. O perfil Initiator definido pelo sistema também concede o nível Initiate em todos os outros fluxos. Utilize um perfil personalizado se os gestores de fundos devem iniciar levantamentos, mas não outras operações sujeitas a governação.
Política do Withdrawal Request: aprovações necessárias: 1, «Always require approval» desativado, política bloqueada.
O resultado: os levantamentos da CFO são concluídos de imediato através do Execute. O levantamento de cada gestor de fundos aguarda uma aprovação — na prática, a da CFO, uma vez que é a única aprovante. Ninguém pode alterar estas regras sozinho, porque a política está bloqueada.
Antes de bloquear, confirme que um pedido do Manage Policies ainda pode ser aprovado sem a pessoa que o inicia: tantos Membros com Approve no Manage Policies quantos o fluxo exigir. Esses Membros aprovam futuras alterações de política e pedidos de desbloqueio. O sistema não verifica isto por si.
Reforço posterior. Quando a empresa decidir que todos os levantamentos, incluindo os da CFO, precisam de revisão, a alteração processa-se através de um pedido de política (aprovação independente obrigatória, uma vez que a política está bloqueada):
O Execute da CFO mantém-se no seu perfil, mas fica inativo. Se a empresa voltar a flexibilizar a política, o caminho rápido da CFO é retomado sem necessidade de reatribuir acessos.
Uma equipa de quatro pessoas no fluxo Withdrawal Request, mostrando como a elegibilidade para aprovação é determinada por pedido:
Membro | Ver | Iniciar | Aprovar | Executar |
|---|---|---|---|---|
Proprietário | Sim | Sim | Sim | Sim |
Alice | Sim | Sim | Sim | - |
Bob | Sim | - | Sim | - |
Charlie | Sim | Sim | - | - |
Política: aprovações necessárias: 2, «Always require approval» ativado (o Execute do Owner fica inativo).
Cenário | Quem tem de aprovar | Motivo |
|---|---|---|
O Owner inicia | Alice e Bob | O Owner está excluído de aprovar o seu próprio pedido; Alice e Bob são os únicos aprovadores restantes, pelo que ambos são necessários. |
Alice inicia | Owner e Bob | Alice está excluída; os aprovadores restantes são o Owner e o Bob. |
Charlie inicia | Quaisquer 2 entre Owner, Alice, Bob | Charlie não tem Approve, pelo que os três aprovadores são elegíveis para os seus pedidos. |
Bob inicia | - | Bob não tem Initiate; não pode criar pedidos de levantamento. Fica em revisão – uma função de aprovador puro que muitas equipas adotam deliberadamente. |