Demande d’approbation ( approval_request )
Représente une décision humaine durable : qui doit approuver, quelles décisions individuelles ont été rendues, quelle politique les agrège et quel résultat terminal a permis au processus de reprendre.
Rôle
Une approval_request n’est pas un e-mail, une notification ou une simple action utilisateur. C’est le fait métier
qui porte la décision humaine agrégée. Le canal utilisé pour solliciter les approbateurs peut changer sans modifier ce modèle.
Les nodes SMTP peuvent résoudre les contacts et leur envoyer un lien d’approbation, mais la décision canonique vit dans
approval_request et ses approval_assignment. Un e-mail envoyé avec succès ne signifie jamais « approuvé ».
Une demande, un assignment par approbateur
L’entreprise définit la population dans laquelle les approbateurs sont résolus. La demande crée un assignment par contact retenu, puis agrège leurs décisions selon son approval_mode.
approver_company_id détermine l’entreprise dont les contacts peuvent porter la responsabilité d’approbation.
Chaque contact retenu reçoit un approval_assignment distinct avec son propre statut, sa décision éventuelle,
son motif de rejet et ses dates de notification/décision.
La demande conserve également l’id de l’instance de processus et le node_id qui l’a créée.
Elle reste donc traçable vers la responsabilité d’orchestration exacte à l’origine de la décision.
Modes d’approbation
| Mode | Intention | Résolution observable |
|---|---|---|
first | Une approbation positive suffit pour résoudre la demande. | La première approbation qui satisfait le mode peut résoudre la demande ; un rejet reçu résout la demande en rejet. |
first_decision | La première décision exploitable doit trancher la demande. | Une décision reçue peut rendre la demande terminale selon la politique appliquée par le node créateur. |
all | Tous les assignments doivent approuver. | La demande n’est approuvée que lorsque tous les assignments sont approved ; un rejet rend la demande rejected. |
Le choix du mode ne sélectionne pas lui-même les personnes. La résolution des contacts — rôles, niveaux de certification, stratégie de sélection et politique de conflit avec le demandeur — appartient au node qui crée la demande.
Cycle de vie
| Statut | Signification |
|---|---|
pending | La demande attend encore une décision ou la satisfaction de sa politique d’agrégation. |
approved | La politique d’approbation est satisfaite. |
rejected | Un rejet a rendu la demande terminale. |
expired | L’échéance expires_at a été atteinte avant résolution. |
cancelled | La demande a été annulée avant une résolution normale. |
Lorsqu’une demande devient terminale, resolved_at est renseigné. resolution_assignment pointe vers
l’assignment qui a déclenché la résolution lorsque cette notion est applicable ; les autres assignments encore pending sont
annulés afin qu’une décision tardive ne puisse plus modifier le résultat.
Ne transformez pas automatiquement expired en rejet métier. L’expiration signifie « aucune décision valide avant l’échéance » ; votre processus doit choisir s’il relance, escalade ou arrête le dossier.
Accès des approbateurs
Chaque assignment peut être associé à une capacité temporaire permettant à son approbateur de consulter et rendre sa décision.
Cette capacité expire avec la demande et reste distincte de l’objet approval_assignment persisté.
- Le lien d’action est destiné à l’approbateur ciblé, pas à être partagé comme une URL publique.
- Une décision déjà rendue ne peut pas être rejouée pour modifier une demande devenue terminale.
- Si
rejection_reason_requiredest activé, un rejet doit fournir une justification non vide.
Dans un processus
Les nodes request_approval et
request_multiple_approvals créent ce modèle
après avoir résolu les approbateurs. L’instance se suspend pendant l’attente puis reprend sur une route correspondant au résultat
terminal : approbation, rejet, expiration ou absence d’approbateur éligible selon le node.
L’approbation humaine reste distincte des actions utilisateur du participant final : pendant l’attente, le parcours utilisateur peut afficher un message de traitement sans demander d’action à l’utilisateur du parcours.
Événements
approval_request.created— la demande et ses assignments sont créés.approval_request.resolved— la demande atteint une décision terminale non expirée.approval_request.expired— l’échéance est atteinte alors que la demande était encore pending.
Ces événements exposent le snapshot public de la demande et permettent de construire un suivi ou un processus secondaire sans dépendre du canal de notification utilisé.