Créer un flux d'approbation avec Power Automate — Numériser les demandes de validation papier et par e-mail

« On imprime le formulaire de demande, on appose le cachet, on le fait circuler au service voisin, et il revient une semaine plus tard. » « On envoie un formulaire Excel en pièce jointe par e-mail, et l’approbation se résume à un e-mail de réponse disant “C’est bon”. » Les entreprises ayant déjà adopté Microsoft 365 nous consultent souvent pour résoudre ce type de problème lié aux demandes et aux approbations.

Power Automate dispose d’un mécanisme dédié appelé Approbations (Approvals), qui permet souvent de créer un flux d’approbation où l’approbateur n’a qu’à cliquer sur un bouton dans Teams ou Outlook, le tout dans le cadre d’une licence déjà en place, sans coût supplémentaire. Mais il existe un écart entre « le premier flux fonctionne » et « ce flux peut être utilisé en toute confiance au quotidien ». Où sont conservés les enregistrements d’approbation ? Que se passe-t-il si l’approbateur laisse la demande sans réponse ? Qui corrige le flux lorsque la personne qui l’a créé quitte l’entreprise ? Cet article présente les briques de base d’un flux d’approbation, les points de conception qui posent souvent problème en pratique, et où placer la limite de ce que Power Automate doit — ou ne doit pas — prendre en charge.

1. L’essentiel avant tout

• Le mécanisme d’approbation de Power Automate repose sur l’action « Démarrer et attendre une approbation ». Vous pouvez choisir parmi cinq types d’approbation : « tout le monde doit approuver », « première réponse », « réponses personnalisées (tous/une personne) » et « approbation séquentielle ».¹
• Les approbateurs peuvent répondre depuis Teams, Outlook, le portail Power Automate ou l’application mobile. Il n’est presque jamais nécessaire d’apprendre à utiliser un nouvel écran juste pour approuver quelque chose.²³
• Pour la collecte des demandes, trois options sont réalistes : Microsoft Forms, une liste SharePoint ou l’application Approbations de Teams. Si vous souhaitez pouvoir lister et compiler les demandes par la suite, construire le flux autour d’une liste SharePoint est le choix classique et sûr.
• L’historique d’exécution d’un flux n’est visible que 28 jours par défaut, et une seule exécution expire au bout de 30 jours maximum. Ne comptez pas sur l’historique d’exécution pour la trace d’audit des approbations : intégrez dès la conception un mécanisme qui réécrit le résultat dans une liste SharePoint ou équivalent.⁴⁵
• Le départ ou la mutation du propriétaire du flux est le plus grand risque opérationnel pour un flux d’approbation. Configurez des copropriétaires et clarifiez la gestion des connexions dès le jour de la mise en service.⁶
• Si vous essayez d’implémenter tel quel un règlement d’approbation formel comportant de nombreuses ramifications conditionnelles, une approbation multi-niveaux, une décision par délégation ou des exigences d’audit strictes, Power Automate devient vite ingérable. Ce cas relève alors d’un système de workflow dédié ou d’un développement sur mesure.

2. Quel est le problème avec les approbations papier et e-mail ?

Ce qui rend les approbations papier ou par Excel joint à un e-mail pénibles n’est pas tant l’effort en lui-même que le fait de ne pas pouvoir voir l’état de la demande. Dans les échanges que nous avons avec nos clients, on retrouve généralement les trois mêmes problèmes.

• Impossible de savoir où la demande est bloquée en ce moment. Le demandeur n’a aucun moyen de savoir sur quel bureau se trouve le formulaire, ou dans quelle boîte de réception l’e-mail est enfoui. Les relances se font oralement ou par téléphone, ce qui n’est agréable pour personne, y compris pour la personne relancée.
• Les enregistrements sont dispersés. La trace des approbations se répartit entre des classeurs papier et des boîtes mail individuelles. Pour un audit ou une vérification ultérieure du type « qui a approuvé cette demande, et quand », il faut fouiller dans la boîte mail d’une personne — et si cette personne quitte l’entreprise, toute la boîte mail disparaît avec elle.
• Les renvois sont difficiles à suivre. Lorsqu’un rejet ou une demande de correction se fait oralement ou par e-mail, on finit par ne plus savoir à quelle version du formulaire la remarque s’appliquait. Renvoyer une version corrigée relance toute la circulation depuis le début.

Ces problèmes se résolvent presque entièrement en rassemblant en un seul endroit l’état et l’enregistrement de la demande. Et si vous avez déjà adopté Microsoft 365, vous disposez déjà de l’emplacement (SharePoint), du canal de notification (Teams/Outlook) et de l’automatisation (Power Automate) nécessaires.

3. Les briques de base d’une approbation Power Automate

L’action « Démarrer et attendre une approbation »

Le cœur d’un flux d’approbation est l’action « Démarrer et attendre une approbation » (Start and wait for an approval) du connecteur Approbations. Vous spécifiez le titre, les détails et les approbateurs de la demande, et le flux s’y arrête, attendant la réponse de l’approbateur avant de passer à l’action suivante.¹

Il existe cinq types d’approbation.¹

Avec les réponses personnalisées, vous pouvez définir des options comme « Approuver », « Renvoyer », « Mettre en attente » au lieu du simple choix « approuver/rejeter ». Cela deviendra un élément de la boucle de renvoi décrite plus loin.

Notez que l’utilisation de la fonctionnalité d’approbation nécessite une base de données Microsoft Dataverse. Les enregistrements des demandes et réponses d’approbation sont stockés dans Dataverse ; dans l’environnement par défaut, cette base est provisionnée automatiquement lors de la création du premier flux d’approbation, si bien qu’on peut généralement commencer sans même y penser. Le connecteur Approbations étant un connecteur standard, une licence incluant les connecteurs standard (comme Office 365) suffit pour créer un flux d’approbation.¹

D’où les approbateurs répondent-ils ?

Les demandes d’approbation parviennent à l’approbateur par e-mail et via l’application mobile Power Automate.³ Dans Outlook, elles arrivent sous forme d’un e-mail d’approbation mis en forme, depuis lequel on peut répondre directement.⁷ Une approbation adressée à un utilisateur individuel est également notifiée dans Teams, où l’on peut approuver, rejeter ou ajouter un commentaire depuis un chat ou l’application Approbations.² Ne pas avoir à faire se connecter les gens sur un site dédié juste pour approuver quelque chose est le principal moteur de l’adoption durable des flux d’approbation.

Un point à surveiller : si la demande est adressée à un groupe Microsoft 365, aucune notification Teams n’est envoyée. Les notifications Teams ne sont envoyées que pour les approbations adressées à un utilisateur individuel.⁸

Vue d’ensemble du flux

En prenant une demande d’achat comme exemple, voici à quoi ressemble l’ensemble.

flowchart TD
    Submit[Le demandeur saisit la demande<br/>envoi du formulaire Forms ou ajout dans la liste SharePoint] --> Trigger[Déclenchement du flux cloud<br/>nouvelle réponse / élément ajouté]
    Trigger --> Record[Enregistrement de la demande<br/>dans la liste SharePoint, statut : en attente d'approbation]
    Record --> Approval[Démarrer et attendre une approbation<br/>envoi de la demande à l'approbateur]
    Approval -- Teams / Outlook / mobile --> Response{Réponse}
    Response -- Approuver --> UpdateOK[Mise à jour du statut à « Approuvé »<br/>enregistrement de l'approbateur, de la date/heure et du commentaire dans les colonnes]
    Response -- Rejeter/renvoyer --> UpdateNG[Mise à jour du statut à « Renvoyé »<br/>notification du motif au demandeur]
    Response -- Délai dépassé --> Remind[Notification de relance / escalade]
    UpdateOK --> NotifyOK[Notification du résultat au demandeur]
    UpdateNG --> Resubmit[Le demandeur corrige et soumet à nouveau]
    Resubmit -- La condition de déclenchement<br/>ne s'active que pour une nouvelle soumission --> Trigger

Le point important est d’insérer une étape d’« enregistrement » à la fois avant et après l’action d’approbation. J’expliquerai pourquoi au chapitre 5.

4. Comment concevoir le point d’entrée des demandes

La facilité d’utilisation d’un flux d’approbation dépend moins du côté approbation que du point d’entrée où le demandeur saisit sa demande. Trois options sont réalistes.

Voici quelques repères pour choisir.

• Si vous voulez simplement numériser des approbations ponctuelles, il n’est même pas nécessaire de créer un flux : l’application Approbations de Teams suffit à elle seule. Cette application permet d’envoyer une demande d’approbation sur-le-champ depuis un chat ; elle fonctionne sur la plateforme Power Automate, mais ne nécessite pas de créer de flux.⁹
• Pour remplacer un formulaire de demande, le plus rapide est d’utiliser Forms comme point d’entrée, de récupérer la réponse dans un flux et de la faire suivre pour approbation. Un modèle prêt à l’emploi permet même d’insérer le contenu de la réponse Forms dans la demande d’approbation.¹¹
• Pour le gérer comme un registre des demandes, construisez le flux autour d’une liste SharePoint. Même si Forms est le point d’entrée, faire transcrire la réponse dans la liste dès le début du flux permet, grâce à une colonne de statut (en attente / approuvé / renvoyé) et à une vue, de rendre visible par tous « où en est la demande en ce moment ». C’est ici, concrètement, que se trouve la réponse aux problèmes des approbations papier et e-mail évoqués en introduction.

Pour démarrer à petite échelle, une configuration « collecte via Forms, enregistrement dans une liste SharePoint, et réécriture du résultat de l’approbation dans cette même liste » permet de combiner facilité de saisie et gestion en registre, et reste facile à mettre en œuvre.

5. Points de conception qui comptent en pratique

Où conserver l’enregistrement des approbations — ne pas compter sur l’historique d’exécution

C’est la décision de conception la plus importante. L’historique d’exécution d’un flux n’est visible que 28 jours par défaut.⁴ Si le flux appartient à une solution, vous pouvez conserver les métadonnées de l’historique d’exécution dans Dataverse, mais la rétention par défaut y est également de 28 jours — c’est un mécanisme où l’administrateur peut ajuster la durée de rétention.¹²

Autrement dit, une pratique consistant à vérifier après coup « qui a approuvé quoi, et quand » via l’historique d’exécution s’effondrera en un mois. Les enregistrements des demandes et réponses d’approbation eux-mêmes sont stockés dans Dataverse¹³, mais consulter une table Dataverse à chaque audit ou vérification courante n’est pas réaliste, et comme l’historique des approbations consomme l’espace de stockage de l’environnement, il peut aussi être supprimé simplement pour libérer de la place.¹⁴

En pratique, ajoutez toujours, immédiatement après l’action d’approbation, une étape qui réécrit le résultat, l’approbateur, la date/heure de réponse et le commentaire dans les colonnes d’une liste SharePoint. L’action « Démarrer et attendre une approbation » renvoie la réponse, l’approbateur et le commentaire comme sorties¹³, il suffit donc de les enregistrer directement dans les colonnes. La demande et l’enregistrement de l’approbation se retrouvent ainsi alignés sur la même ligne de la même liste, et la durée de conservation peut aller aussi loin que vous le souhaitez, selon la façon dont vous exploitez la liste.

Un point à surveiller : pour les types d’approbation impliquant plusieurs approbateurs, comme « tout le monde doit approuver » ou les réponses personnalisées (tous), la sortie Réponses (Responses) revient sous forme d’un tableau comportant une entrée par personne.³ L’écrire dans un seul jeu de colonnes par écrasements successifs ne conserve que la dernière réponse ; pour plusieurs approbateurs, il faut donc soit ajouter une ligne par réponse dans une liste d’historique, soit mettre en forme l’ensemble des réponses en un seul texte avant de l’enregistrer dans une colonne.

Délais et relances — impossible de créer une « approbation sans échéance »

Une seule exécution de flux cloud dure au maximum 30 jours. Cette période de 30 jours inclut les étapes en attente, comme l’attente d’une approbation, et au-delà de 30 jours, l’étape en attente expire.⁵ Si l’approbateur laisse la demande sans réponse, le flux se termine silencieusement en échec. Démarrer une exploitation sans le savoir provoque l’incident le plus dommageable pour la confiance : « j’ai soumis une demande et il ne s’est rien passé du tout ».

La parade se joue en deux temps.

1. Définissez un délai d’expiration explicite sur l’action d’approbation. Spécifiez un délai au format ISO 8601 (par exemple P3D pour 3 jours) dans les paramètres de l’action, et ajoutez une branche « en cas d’expiration du délai » dans Configurer l'exécution en fonction de.¹⁵ Ce qu’il faut retenir ici, c’est qu’au moment où le délai expire, l’attente d’approbation initiale est déjà terminée. Même si l’approbateur répond ensuite, cette réponse ne circule plus vers les étapes suivantes de cette exécution (réécriture du résultat, etc.). Autrement dit, la branche de délai expiré n’est pas un endroit où « continuer d’attendre tout en relançant », mais un endroit où « interrompre une fois pour prendre la mesure suivante ». Pour relancer, envoyez la notification dans la branche de délai expiré, puis émettez une toute nouvelle demande d’approbation. Pour un enchaînement du type « relance à 3 jours, escalade à un supérieur à 7 jours », l’approche la plus simple et la plus fiable consiste à enchaîner en série 2 à 3 actions d’approbation avec délai (la deuxième étape relance la demande avec un rappel, la troisième s’adresse à un supérieur). On peut aussi encapsuler « délai expiré → relance → nouvelle demande » dans une boucle Do Until, mais celle-ci possède sa propre limite (60 itérations / 1 heure par défaut), et si vous y placez une action de longue durée comme une attente d’approbation, les itérations suivant la première ne démarreront pas tant que vous n’aurez pas explicitement prolongé le délai de la boucle via « Modifier les limites ».⁵¹⁶
2. Pour toute approbation susceptible de dépasser 30 jours, scindez le flux en deux. Microsoft documente officiellement une configuration où l’action « Créer une approbation (v2) » envoie uniquement la demande d’approbation puis met fin au premier flux, le traitement ultérieur de la réponse étant assuré par un second flux. Comme l’enregistrement d’approbation se trouve dans Dataverse, la réponse peut toujours être traitée même après la fin de l’exécution du flux d’origine. Si vous souhaitez organiser des relances flexibles sans jamais interrompre l’attente, cette configuration en deux flux est également plus naturelle à mettre en œuvre.¹⁷ Notez qu’il existe une marge de conception quant au déclenchement du second flux ; si vous choisissez de récupérer directement les modifications de la table d’approbation via un déclencheur du connecteur Dataverse, gardez à l’esprit que ce connecteur est classé dans le niveau premium (les actions du connecteur Approbations lui-même restent dans le niveau standard¹).¹⁸

Pour le processus d’approbation d’une PME, l’approche réaliste consiste d’abord à fixer une règle interne du type « relance à 3 jours, escalade au responsable à 7 jours », puis à l’implémenter soit sous forme d’une boucle de nouvelle demande, soit sous forme de deux flux distincts.

Réattribution en cas d’absence

Il arrivera forcément qu’un approbateur soit indisponible pendant une longue période. La personne qui a reçu la demande d’approbation peut la réattribuer à quelqu’un d’autre depuis la liste des approbations du portail Power Automate. Du côté du demandeur, remédier à la situation implique d’annuler la demande, de changer l’approbateur du flux, puis de le relancer.⁷ Il est important de noter que, pour un flux à déclenchement automatique comme celui de cet article, cette opération relève du propriétaire du flux, et non du demandeur — car la demande d’approbation part du compte utilisé pour la connexion du flux, et changer l’approbateur nécessite les droits de modification du flux. Il faut décider, en lien avec la question des copropriétaires abordée au chapitre suivant, qui corrige le flux lorsque l’approbateur est en congé.

Cela dit, la réattribution suppose que « la personne qui a reçu la demande puisse agir », donc elle ne fonctionne pas en cas d’absence soudaine et imprévue. En prévention permanente, il est plus sûr d’éviter de figer l’approbateur sur une seule personne nommée, et de plutôt spécifier plusieurs personnes séparées par des points-virgules avec un type « première réponse », ou d’adresser la demande à un groupe.⁷ Comme adresser la demande à un groupe empêche l’envoi des notifications Teams⁸, choisissez l’option des plusieurs noms si la fiabilité de la notification compte plus pour vous.

La boucle de rejet et de renvoi

La partie la plus difficile à suivre dans une approbation papier — « renvoi → correction → nouvelle soumission » — peut s’exprimer simplement avec une conception basée sur une colonne de statut. La forme de base est la suivante.

• Définir « Approuver » et « Renvoyer » comme réponses personnalisées¹
• En cas de renvoi, faire passer la colonne de statut de la liste à « Renvoyé », enregistrer le commentaire de l’approbateur dans une colonne, et notifier le demandeur
• Le demandeur corrige l’élément de la liste et fait passer le statut à « Nouvelle soumission » (ou soumet à nouveau via Forms)
• La mise à jour de l’élément déclenche à nouveau le flux, qui repart vers l’approbation

Un point de vigilance avec cette conception : la réécriture effectuée par le flux lui-même peut le redéclencher. Si le déclencheur reste « Lorsqu’un élément est créé ou modifié », alors au moment où le flux met à jour la colonne de statut vers « En attente d’approbation » ou « Approuvé », cette mise à jour elle-même satisfait la condition de déclenchement, provoquant des demandes d’approbation en double ou une boucle infinie. Un flux cloud peut se déclencher lui-même, et Power Automate avertit d’ailleurs du risque de boucle infinie lors de l’enregistrement.¹⁹ La solution ne consiste pas à écarter le cas dans une branche conditionnelle en aval, mais à écrire la règle directement dans le déclencheur, via les conditions de déclenchement (trigger conditions), de sorte qu’il ne se déclenche que lorsque la colonne de statut vaut « Nouvelle soumission » (ou lors d’une création). Une mise à jour qui ne satisfait pas la condition de déclenchement n’entraîne même pas l’exécution du flux, et ne consomme donc pas non plus de compteur d’exécution.²⁰

Comme l’historique des corrections est conservé dans l’historique des versions de la liste, cela résout aussi le problème de confusion sur « quelle version la remarque concernait ». Il est possible de construire une boucle Do Until à l’intérieur du flux pour faire circuler les renvois au sein d’une seule exécution, mais comme la limite de 30 jours sur la durée d’exécution engloberait alors aussi le temps d’aller-retour de chaque renvoi, il est plus sûr de concevoir le flux pour que chaque renvoi termine l’exécution, et que la nouvelle soumission démarre une exécution neuve.

6. Exploitation et gouvernance — ne laissez pas le flux devenir « la propriété de son créateur »

Un flux d’approbation s’insère au cœur des processus métier ; le laisser dépendre d’une seule personne crée un risque disproportionné. Au minimum, réglez ces deux points dès le premier jour de mise en service.

• Configurez des copropriétaires. Le propriétaire d’un flux peut consulter l’historique d’exécution, modifier ou arrêter le flux, et même mettre à jour les identifiants des connexions. S’il reste limité à un seul créateur, le flux devient impossible à corriger par quiconque dès que cette personne quitte l’entreprise ou change de poste. Ajoutez votre service informatique ou un successeur potentiel comme copropriétaires. Il existe aussi une fonctionnalité permettant de faire de la liste SharePoint elle-même une copropriétaire, alignant ainsi « quiconque peut modifier la liste » sur « quiconque peut modifier le flux »⁶, mais si vous faites cela sur une liste dans laquelle tous les demandeurs écrivent, comme dans la configuration de cet article, vous finissez par accorder les droits de modification du flux à tous les demandeurs. N’utilisez pas cette fonctionnalité pour un flux d’approbation : limitez les copropriétaires aux personnes individuelles chargées de l’exploitation, ou à un groupe d’administrateurs.
• Comprenez la gestion des connexions. Une connexion utilisée par un flux (authentification à SharePoint ou Outlook, par exemple) est liée à l’utilisateur qui l’a créée, et une connexion partagée ne peut être utilisée qu’à l’intérieur de ce flux spécifique. Un copropriétaire ne peut pas non plus modifier les identifiants d’une connexion créée par un autre propriétaire.⁶ Des incidents comme « les e-mails de notification d’approbation continuent d’être envoyés depuis le compte d’un employé parti » ou « le flux s’arrête dès que ce compte est désactivé » découlent de cela. Le choix du compte utilisé pour les notifications et les écritures est un point à trancher avant de construire le flux, pas après.

Notez également que même si vous faites utiliser le flux par d’autres services, il n’est pas nécessaire de partager le flux lui-même avec les personnes qui soumettent des demandes. Dans la configuration de cet article, le flux se déclenche automatiquement dès lors que les personnes peuvent saisir des données dans le point d’entrée (Forms ou la liste SharePoint). Le partage doit être limité aux personnes impliquées dans la modification et l’exploitation, et les copropriétaires réduits au strict minimum nécessaire.²¹

La gouvernance globale de Power Automate — licences, séparation des environnements, politiques DLP — est traitée dans un autre article, « Automatiser les processus métier avec Power Automate — Choisir entre flux cloud et flux de bureau, et concevoir la gestion des erreurs ». Un flux d’approbation n’étant qu’un type de flux cloud parmi d’autres, la même logique s’applique directement.

7. Jusqu’où aller avec Power Automate ?

Le mécanisme d’approbation de Power Automate est puissant, mais ce n’est pas un outil destiné à implémenter tel quel un règlement d’approbation formel. Voici quelques repères pour tracer la limite.

Comme repère intuitif, je considère qu’à partir du moment où le schéma des ramifications du flux dessiné sur papier ne tient plus sur une feuille A4, on commence à dépasser le domaine couvert par Power Automate. Plutôt que de forcer le flux à grossir, il est souvent moins coûteux au final de sortir uniquement la logique de décision du parcours d’approbation (vers une table Dataverse ou un système séparé), ou de basculer entièrement vers un système dédié.

La numérisation du flux d’approbation est aussi souvent une porte d’entrée pour repenser les échanges papier et fax avec l’extérieur de l’entreprise. Une fois les approbations internes numérisées, les commandes reçues par fax et les échanges de factures deviennent les candidats naturels suivants. Ces sujets sont traités dans « Faire migrer les commandes par fax vers le Web — Concevoir une période de double exploitation et les aspects pratiques d’une migration progressive » et « Qu’est-ce que l’EDI ? Simplifier les commandes interentreprises — Du fax, de l’e-mail et de la saisie manuelle à l’intégration de données ».

8. Conclusion

Le véritable problème des approbations papier et e-mail n’était pas l’effort en lui-même, mais le fait que « l’état est invisible, les enregistrements sont dispersés, et les renvois sont impossibles à suivre ». Un flux d’approbation Power Automate résout ces trois points en rassemblant la demande et l’enregistrement d’approbation dans une liste SharePoint, et en réalisant l’action d’approbation elle-même via Teams ou Outlook. Pouvoir démarrer sans investissement système supplémentaire, dans de nombreux cas, est aussi un avantage réel pour les entreprises ayant déjà adopté Microsoft 365.

En revanche, construire un flux sans connaître les contraintes de 28 jours pour l’historique d’exécution et de 30 jours pour la durée d’exécution aboutit à un flux d’approbation où « la trace disparaît » et où « les demandes échouent silencieusement ». Réécriture du résultat, branche de délai expiré, gestion de plusieurs approbateurs, copropriétaires : intégrez ces quatre points dès la conception, et un flux d’approbation pourra fonctionner longtemps et en toute confiance. Et le moment où vous ressentez l’envie d’implémenter tel quel toute la complexité d’un règlement d’approbation formel est précisément le signal qu’il faut envisager un système dédié ou un développement sur mesure.

Articles connexes

• Automatiser les processus métier avec Power Automate — Choisir entre flux cloud et flux de bureau, et concevoir la gestion des erreurs
• Faire migrer les commandes par fax vers le Web — Concevoir une période de double exploitation et les aspects pratiques d’une migration progressive
• Qu’est-ce que l’EDI ? Simplifier les commandes interentreprises — Du fax, de l’e-mail et de la saisie manuelle à l’intégration de données
• Qu’est-ce qu’une facture électronique ? En quoi diffère-t-elle du simple envoi d’un PDF de facture par e-mail ?

Domaines de consultation connexes

Komura Software LLC accompagne aussi bien le conseil sur la numérisation des processus métier avec Microsoft 365 que la mise en système des exigences d’approbation et de reporting qui dépassent ce que Power Automate peut gérer.

• Consultation technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Peut-on créer un flux d'approbation Power Automate avec une simple licence Microsoft 365 ?

Oui. Le connecteur Approbations est un connecteur standard, donc toute licence incluant les connecteurs standard (comme Office 365) suffit pour créer un flux d'approbation. Cela dit, les données d'approbation nécessitent une base de données Microsoft Dataverse comme emplacement de stockage ; dans l'environnement par défaut, elle est provisionnée automatiquement lors de la création du premier flux d'approbation. La combinaison avec une liste SharePoint, Forms, Teams ou Outlook peut également se faire entièrement avec des connecteurs standard.

Que se passe-t-il si un approbateur ne répond jamais ?

Une seule exécution de flux cloud dure au maximum 30 jours, et toute étape en attente, y compris une approbation en cours, expire une fois ce délai dépassé — il n'existe donc aucun moyen de créer une « approbation sans échéance ». En pratique, on définit un délai d'expiration explicite sur l'action d'approbation et on ajoute une branche « en cas d'expiration du délai » dans Configurer l'exécution en fonction de. Une fois le délai expiré, l'attente d'approbation initiale est terminée, et si l'approbateur répond ensuite, cette réponse ne circule plus vers les étapes suivantes de l'exécution — il faut donc concevoir la branche de délai expiré pour envoyer une relance et émettre une toute nouvelle demande d'approbation (en escaladant vers une personne plus haut placée à mesure que le nombre de tentatives augmente), et non pour continuer d'attendre tout en relançant. Si vous avez réellement besoin d'attendre plus de 30 jours, scindez le travail en deux flux : l'un utilisant l'action Créer une approbation (V2), et un second flux distinct qui traite la réponse.

Où finissent les enregistrements d'approbation, et peuvent-ils servir à des audits ?

Les demandes et réponses d'approbation sont stockées sous forme d'enregistrements dans Microsoft Dataverse, et l'historique d'exécution du flux lui-même n'est visible que 28 jours par défaut. S'appuyer sur l'historique d'exécution pour des audits ou des vérifications ultérieures est risqué. En pratique, je recommande de réécrire le résultat de l'approbation, l'approbateur, la date/heure et le commentaire dans les colonnes d'une liste SharePoint à la fin du flux, afin que les données de la demande et l'enregistrement de l'approbation puissent être consultés au même endroit.

Que faire lorsqu'un approbateur est indisponible ou a quitté l'entreprise ?

La personne ayant reçu la demande d'approbation peut la réattribuer à quelqu'un d'autre depuis sa liste d'approbations Power Automate. Le demandeur ne peut pas réattribuer directement, mais peut annuler la demande, changer l'approbateur du flux, puis le relancer. Pour se prémunir contre les absences prolongées, il est conseillé de désigner l'approbateur comme plusieurs personnes ou un groupe plutôt qu'un seul individu fixe, ce qui réduit fortement le risque de blocage. Il est également important de configurer des copropriétaires pour le flux lui-même dès le départ, au cas où son propriétaire quitterait l'entreprise.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.