Ce guide vous explique comment introduire des exigences d'approbation dans votre Organisation, un flux de travail à la fois. Vous n'avez pas besoin de configurer toute la gouvernance en une seule fois – le système est conçu pour vous permettre de faire évoluer chaque flux de travail à votre rythme, des opérations rapides en mode mono-utilisateur vers une approbation multi-parties entièrement encadrée.
Pour comprendre le fonctionnement des politiques et des paramètres d'approbation, consultez Politiques, approbations et gouvernance. Pour le modèle de permissions, consultez Permissions et flux de travail.
L'interaction entre Execute et "Always require approval" vous offre deux options de gouvernance par flux de travail :
Les trois premières étapes sont réversibles. La quatrième – le verrouillage – est le point de non-retour.
Le Propriétaire dispose au départ de l'ensemble des autorisations sur tous les workflows. À ce stade, le Propriétaire est le seul Membre et peut effectuer toute action sans approbation. C'est l'état initial par défaut.
Configurez les approbations pour un workflow spécifique pendant que "Always require approval" reste désactivé. Le propriétaire conserve Execute et peut continuer à travailler normalement.
À l'issue de cette étape, les règles d'approbation sont définies et les bonnes personnes disposent des permissions requises, mais rien n'est encore appliqué. Le propriétaire peut toujours effectuer des actions via Execute et modifier les politiques seul.
Activez "Always require approval" (ON) pour le workflow cible. Cette option force toutes les actions, y compris celles du propriétaire, à passer par le circuit d'approbation. Vérifiez que :
La politique n'étant pas encore verrouillée, vous pouvez toujours revenir en arrière. Désactivez "Always require approval" (OFF) pour restaurer l'exécution immédiate et ajuster la configuration avant de recommencer.
C'est la fenêtre d'expérimentation sans risque. La gouvernance est en vigueur pour le workflow cible, mais le propriétaire conserve un contrôle unilatéral sur la politique elle-même et peut revenir en arrière à tout moment.
Une fois la configuration validée, verrouillez la politique. C'est le point de non-retour. À partir de là :
Important : Avant de verrouiller, assurez-vous qu'au moins un autre membre actif dispose de l'autorisation Approve sur le workflow Manage Policies. Le système exige un approbateur indépendant avant d'autoriser le verrouillage.
Important : Le verrouillage empêche toute personne seule d'affaiblir la gouvernance de ce workflow. Toute modification ultérieure, y compris le déverrouillage, nécessite qu'un approbateur indépendant reste disponible via le workflow Manage Policies.
Tous les autres workflows restent en accès rapide – l'Owner peut continuer à utiliser Execute sur tout workflow dont la politique n'a pas été verrouillée. Revenez à l'étape 2 pour le workflow suivant.
Cette progression est une recommandation, non une obligation. Vous pouvez fonctionner indéfiniment avec toute combinaison de workflows gouvernés et non gouvernés.
Un CFO souhaite conserver la possibilité d'effectuer des retraits immédiatement, tout en imposant à tous les Fund Managers de soumettre leurs retraits à une validation.
Configuration des permissions :
Membre | Afficher | Initier | Approuver | Exécutez |
|---|---|---|---|---|
CFO | Oui | Oui | Oui | Oui |
Fund Manager A | Oui | Oui | — | — |
Fund Manager B | Oui | Oui | — | — |
Paramètres de la politique :
Le directeur financier peut initier et finaliser immédiatement des retraits via Execute. Les gestionnaires de fonds peuvent initier des retraits, mais chaque demande entre dans la file d'attente d'approbation et nécessite 1 approbation du directeur financier.
Passage à une gouvernance complète : Lorsque le directeur financier décide ultérieurement que tous les retraits, y compris les siens, doivent passer par une approbation, il soumet une demande de modification de politique (qui nécessite elle-même une approbation indépendante, car la politique est verrouillée) :
Après ce changement, la permission Execute du CFO reste attribuée mais n'a aucun effet. La politique exige désormais une approbation indépendante pour chaque demande, y compris celles du CFO.
Conserver Execute même lorsqu'il n'a aucun effet préserve le périmètre d'accès du Membre dans la matrice des permissions. Cela sera particulièrement utile lorsque la prise en charge multi-comptes sera disponible, Execute définissant alors les comptes sur lesquels un Membre peut agir.
Cet exemple présente un workflow Initiate Withdrawal entièrement configuré et illustre l'interaction entre permissions et politique en pratique. La mise en page reflète la matrice des permissions visible dans l'interface du produit.
Membre | Afficher | Initier | Approuver | Exécutez |
|---|---|---|---|---|
Organization Owner | Oui | Oui | Oui | Oui |
Alice | Oui | Oui | Oui | — |
Bob | Oui | — | Oui | — |
Charlie | Oui | Oui | — | — |
Politique : Approbations requises : 2 des 3 approbateurs disponibles. Toujours exiger une approbation : ACTIVÉ.
Le Owner dispose d'Execute, mais comme "Always require approval" est activé, cette permission n'a aucun effet.
Chaque demande de retrait doit être approuvée par 2 Membres indépendants. La personne qui initie la demande est exclue du groupe d'approbateurs pour cette demande.
Scénario | Qui initie | Qui doit approuver | Pourquoi |
|---|---|---|---|
Retrait du Owner | Propriétaire | Alice et Bob | Seuls 2 membres disposant de l'autorisation Approuver restent après exclusion du propriétaire. Les deux doivent approuver. |
Alice effectue un retrait | Alice | Le propriétaire et Bob | Alice est exclue. Les approbateurs restants sont le propriétaire et Bob. |
Charlie effectue un retrait | Charlie | 2 au choix parmi : Le propriétaire, Alice, Bob | Charlie ne dispose pas de l'autorisation Approuver, donc les 3 approbateurs sont éligibles. 2 approbateurs suffisent. |
Bob initie | — | — | Bob ne dispose pas de l'autorisation Initier. Il ne peut pas créer de demande de retrait. Il peut uniquement approuver. |