Ce guide explique comment introduire des exigences d'approbation flux par flux. Le système est conçu pour une adoption progressive : votre Organisation démarre rapidement, le Propriétaire pouvant tout faire seul, et vous renforcez chaque flux dès que vous êtes prêt, pour aboutir, si vous le souhaitez, à une configuration où aucune personne ne peut transférer des fonds ou modifier les règles de manière autonome.
Pour les mécanismes des politiques, consultez Politiques, approbations et gouvernance. Pour le modèle d'accès, consultez Rôles, profils et autorisations.
Le niveau Execute et le paramètre "Toujours exiger une approbation" se combinent en deux configurations :
Chaque flux peut adopter une configuration différente. Configuration courante : approbations pour tous sur Withdrawal Request, accès direct sur Transfer Request (les fonds restent au sein de l'Organisation), et approbations sur Manage Policies pour protéger les règles elles-mêmes.
Les trois premières étapes sont réversibles à tout moment. Le verrouillage, lui, est définitif.
Étape 1 - Initialisation
Le propriétaire démarre avec le profil Admin défini par le système et le rôle Accès complet : Droit d'exécution sur chaque workflow, toutes les autorisations sur chaque compte. La politique de chaque workflow est initialement ouverte. En tant qu'Organisation à utilisateur unique, vous fonctionnez exactement comme avant : aucune demande n'attend d'approbation, car il n'y a personne pour approuver.
Étape 2 - Configuration
Configurez le processus d'approbation pour un workflow – généralement Demande de retrait en premier – tandis que l'option "Toujours exiger une approbation" reste désactivée :
Seuls les membres ayant accepté leur invitation et finalisé leur vérification sont comptabilisés dans le quorum d'approbation. Un membre invité n'est pas comptabilisé tant que ces deux conditions ne sont pas remplies, même s'il figure dans votre liste d'équipe.
Aucune règle n'est encore en vigueur. Vous conservez Execute et continuez à travailler normalement pendant la mise en place des éléments.
Étape 3 – Valider
Activez "Always require approval" pour le workflow cible. Toutes les demandes, y compris les vôtres, passent désormais en file d'attente. Vérifiez avec des demandes réelles :
C'est la fenêtre de test sans risque : la gouvernance est en vigueur, mais la politique n'est pas verrouillée – vous pouvez donc désactiver le paramètre, ajuster et recommencer autant de fois que nécessaire. Décidez si la configuration finale doit conserver "Always require approval" activé ou le désactiver avant de verrouiller la politique.
Étape 4 – Verrouiller
Verrouillez la politique. Le verrouillage constitue lui-même une demande Manage Policies : si Manage Policies requiert déjà une approbation, le verrouillage prend effet dès qu'un autre membre l'approuve. À partir de ce moment :
Le verrouillage supprime la capacité de toute personne seule à affaiblir la gouvernance de ce flux de travail. Toute modification future, y compris le déverrouillage, requiert qu'un approbateur indépendant reste disponible via Manage Policies. Pensez à maintenir une couverture d'approbateurs suffisante lorsque des membres changent de rôle ou quittent l'organisation.
Étape 5 – Répéter
Chaque autre workflow conserve sa configuration actuelle jusqu'à ce que vous y reveniez à l'étape 2. Toute combinaison de workflows gouvernés et non gouvernés constitue un état stable valide ; la progression est une recommandation, non une obligation.
Étape finale – verrouiller Manage Policies
Manage Policies dispose de sa propre politique et de son propre verrou. Le verrouiller marque l'aboutissement du déploiement : toute modification de règle dans l'Organisation – paramètres de politique, verrouillages et déverrouillages, sur chaque workflow – requiert dès lors une approbation indépendante, et personne ne peut assouplir la gouvernance seul via le produit.
Effectuez cette étape en dernier, une fois que tous les workflows à gouverner sont configurés et verrouillés. Vérifiez d'abord qu'une demande Manage Policies peut toujours être initiée et approuvée sans vous : un membre capable de la lancer, plus autant de membres disposant du niveau Approve sur Manage Policies que le workflow l'exige, tous vérifiés et actifs. Les politiques verrouillées ne restent modifiables que tant que ce circuit existe ; le système ne le vérifie pas à votre place. Consultez Politiques, approbations et gouvernance pour en savoir plus sur le comportement de ce verrou.
Une directrice financière souhaite effectuer ses propres retraits immédiatement, tandis que chaque retrait des gestionnaires de fonds passe par sa validation.
Profils de workflow :
Membre | Profil | Niveaux pour Withdrawal Request |
|---|---|---|
CFO | Personnalisé "CFO" | Consulter, Initier, Approuver, Exécuter |
Gestionnaire de fonds A | Initiator (défini par le système) | Consulter, Initier |
Gestionnaire de fonds B | Initiator (défini par le système) | Consulter, Initier |
Les trois membres détiennent un rôle de compte autorisant les retraits sur les comptes opérationnels. Les niveaux présentés dans cet exemple concernent uniquement la demande Withdrawal Request. Le profil Initiator défini par le système accorde également le niveau Initiate sur tous les autres workflows. Utilisez un profil personnalisé si les gestionnaires de fonds doivent initier des retraits, mais pas d'autres opérations soumises à la gouvernance.
Politique Withdrawal Request : approbations requises : 1, "Always require approval" : désactivé, politique verrouillée.
Résultat : les retraits de la DAF sont exécutés immédiatement via Execute. Le retrait de chaque gestionnaire de fonds est soumis à une approbation – en pratique, celle de la DAF, qui est la seule approbatrice. Personne ne peut modifier ces règles seul, car la politique est verrouillée.
Avant de verrouiller, vérifiez qu'une demande Manage Policies peut toujours être approuvée sans la personne qui la soumet : autant de membres disposant d'Approve sur Manage Policies que ce workflow l'exige. Ces membres approuvent les futures modifications de politique et les demandes de déverrouillage. Le système ne vérifie pas cela à votre place.
Renforcement a posteriori. Lorsque la société décide que tous les retraits, y compris ceux de la DAF, doivent être examinés, la modification passe par une demande de politique (approbation indépendante requise, la politique étant verrouillée) :
L'Execute de la DAF reste sur son profil, inactif. Si la société assouplit de nouveau la politique, son accès rapide reprend sans qu'il soit nécessaire de réattribuer des droits.
Une équipe de quatre personnes sur le workflow Withdrawal Request, illustrant la résolution de l'éligibilité à l'approbation par demande :
Membre | Afficher | Initier | Approuver | Exécutez |
|---|---|---|---|---|
Propriétaire | Oui | Oui | Oui | Oui |
Alice | Oui | Oui | Oui | - |
Bob | Oui | - | Oui | - |
Charlie | Oui | Oui | - | - |
Politique : approbations requises : 2, "Always require approval" : activé (l'Execute du propriétaire est donc inactif).
Scénario | Qui doit approuver | Motif |
|---|---|---|
L'Owner initie | Alice et Bob | L'Owner ne peut pas approuver sa propre demande ; Alice et Bob sont les seuls autres approbateurs, et les deux sont requis. |
Alice initie | L'Owner et Bob | Alice est exclue ; les approbateurs restants sont l'Owner et Bob. |
Charlie initie | 2 parmi l'Owner, Alice et Bob | Charlie ne dispose pas du niveau Approve ; les trois approbateurs sont donc éligibles pour ses demandes. |
Bob initie | - | Bob ne dispose pas du niveau Initiate ; il ne peut pas créer de demandes de retrait. Il intervient en approbateur pur, un rôle que de nombreuses équipes choisissent délibérément. |