Démarrage rapide : workflow d'approbation des achats

Ce tutoriel utilise une demande d'achat minimale pour parcourir le cycle complet : définir les ressources, construire le workflow, vérifier la conception et valider son exécution. À la fin, un demandeur peut soumettre une demande d'achat, son responsable de département peut l'approuver et les achats d'un montant élevé sont transmis au service financier.

1. Prérequis

Avant de commencer, vérifiez les points suivants :

• L'application courante possède une version modifiable au statut DEVELOPING.
• Des utilisateurs ou rôles de test sont disponibles pour Applicant, Department Manager et Finance Approver.
• Le département du demandeur permet d'identifier son responsable.
• Vous disposez des droits de modification des ressources de processus et de publication de l'application.

2. Créer les champs

Ouvrez Process Designer → Task Configuration → Fields et créez les champs personnalisés suivants :

Label	Field Type	Configuration principale
Applicant Department	Department	Sélection d'un seul département
Amount	Number	Unité monétaire configurable si nécessaire
Category	Select	Hardware, Software, Service
Required Date	Date	Date
Reason	Text Area	Texte long
Attachments	Attachment	Limiter le nombre et les types de fichiers selon le besoin
Department Review Comment	Text Area	Avis saisi par le responsable de département
Department Review Result	Select	Options Approved et Rejected ; valeur écrite automatiquement par le workflow
Finance Review Comment	Text Area	Avis saisi par l'approbateur financier
Finance Review Result	Select	Options Approved et Rejected ; valeur écrite automatiquement par le workflow

Le système génère le Field Key lors de l'enregistrement du champ. L'utilisateur n'a pas à le saisir et ne peut pas le faire. Pour configurer ensuite des conditions de workflow, des règles d'affectation ou du TQL, sélectionnez les champs proposés par l'éditeur au lieu de déduire une clé à partir du Label.

Utilisez les champs système pour le titre, le statut, le créateur, le responsable, la date de création et les propriétés similaires. Ne créez pas de champs personnalisés synonymes.

Ne définissez pas de valeur par défaut pour Department Review Result et Finance Review Result, et ne demandez pas au demandeur ou à l'approbateur de les sélectionner manuellement. Leur valeur initiale reste vide ; la Post Function de la transition Approve ou Reject correspondante écrit le résultat.

Résultat attendu : la liste Fields contient les champs système et les dix champs personnalisés ci-dessus.

3. Créer les formulaires

Commencez par distinguer les deux types de liaison afin de ne pas considérer un formulaire d'approbation comme un quatrième formulaire du Task Type :

• Un formulaire de Task Type ne possède que trois emplacements : Create Form, Edit Form et View Form.
• Un formulaire de transition est associé à une transition précise du Workflow et ne s'ouvre que lorsque l'utilisateur clique sur Approve ou Reject.

Ouvrez Task Configuration → Forms et créez les ressources de formulaire suivantes :

• purchaseCreate : Create Form. Le demandeur renseigne le titre, le département, le montant, la catégorie, la date souhaitée, le motif et les pièces jointes lors de la création de la tâche.
• purchaseView : View Form. Il présente en lecture seule les informations de la demande, Department Review Result, Department Review Comment, Finance Review Result et Finance Review Comment dans une vue de détail unique. Cet exemple n'autorise pas la modification des champs métier après soumission ; Edit Form utilise donc également purchaseView. Si le métier autorise le demandeur à modifier une tâche non terminée, réutilisez purchaseCreate ou créez un formulaire purchaseEdit distinct.
• managerReview : formulaire de transition de Department Review. Les informations de la demande sont en lecture seule ; seul Department Review Comment est modifiable par le responsable de département.
• financeReview : formulaire de transition de Finance Review. Les informations de la demande sont en lecture seule ; seul Finance Review Comment est modifiable par l'approbateur financier.

À ce stade, créez uniquement les ressources de formulaire. Il n'est pas encore nécessaire de les associer à un Task Type. Une fois le workflow et le schéma d'autorisation prêts, créez toutes les références ensemble à la section 6.

Résultat attendu : la liste Forms contient les quatre ressources purchaseCreate, purchaseView, managerReview et financeReview.

4. Créer les étapes et le workflow

Dans Task Configuration → Steps, créez :

• Department Review
• Finance Review

Un Step est une ressource d'étape métier réutilisable par plusieurs Workflows, et pas seulement le nom affiché d'un nœud du workflow courant. Lorsqu'une Human Activity est liée à un Step, les tâches d'exécution enregistrent son stepCode stable. Les rapports multi-workflows, le TQL, les durées de traitement et les statistiques SLA peuvent ainsi agréger la même étape métier entre plusieurs Workflows.

Par exemple, si Purchase Approval et Expense Reimbursement nécessitent tous deux une approbation financière, liez leur nœud financier au Step Finance Review créé ici. Vous pourrez ensuite mesurer, sur les deux workflows, le volume de tâches, la durée moyenne de traitement et le taux de violation SLA de Finance Review. Ne créez pas deux nœuds temporaires qui portent seulement le même nom : sans identifiant Step commun, ils ne peuvent pas être analysés de manière fiable comme une même étape métier réutilisable.

La même règle s'applique à Department Review. Réutilisez ce Step dans un autre workflow si l'examen par le département a le même sens métier. Si les responsabilités, le périmètre statistique ou la définition SLA diffèrent, créez un Step distinct afin de ne pas fusionner à tort des étapes métier différentes.

Ouvrez ensuite Task Configuration → Workflows et créez :

• Name : Purchase Approval
• Key : saisissez un identifiant stable conforme aux règles de l'interface, par exemple PURCHASEAPPROVAL. Après l'enregistrement, ne changez pas la Key uniquement pour modifier le nom affiché.
• Category : Procurement
• Allow Revoke : activez cette option si le métier l'exige.

Configurez le canevas comme suit :

Start → Department Review → Amount Gateway
                         ├─ Faible montant → Approved
                         └─ Montant élevé → Finance Review → Approved

Department Review / Finance Review refusé → Rejected

La configuration du schéma comprend le routage, les responsables, les formulaires, les validations et l'écriture des résultats :

1. Sur le Task Type, associez purchaseCreate à Create Form et purchaseView à View / Edit Form.
2. Pour Department Review, déterminez le responsable du département à partir de Applicant Department. Pour Finance Review, sélectionnez le rôle Finance Approver.
3. Après l'approbation de Department Review, dirigez le flux vers Amount Gateway. Configurez Amount < 10000 sur la transition de faible montant vers Approved et Amount >= 10000 sur la transition de montant élevé vers Finance Review.
4. Sélectionnez les transitions sortantes Approve et Reject de Department Review, puis choisissez managerReview dans Transition Form dans le panneau droit.
5. Sélectionnez les transitions sortantes Approve et Reject de Finance Review, puis choisissez financeReview dans Transition Form dans le panneau droit.
6. Laissez Show Button activé et définissez pour chaque transition un nom, un message de confirmation et une indication explicites.
7. Ajoutez une validation obligatoire des avis : contrôlez Department Review Comment sur les transitions du département et Finance Review Comment sur celles du service financier.
8. Ajoutez Functions → Set Task Field à la transition Approve de Department Review. Sélectionnez Department Review Result comme Field Name et saisissez Approved comme Field Value.
9. Ajoutez Functions → Set Task Field à la transition Reject de Department Review. Sélectionnez Department Review Result comme Field Name et saisissez Rejected comme Field Value.
10. Configurez Finance Review Result de la même façon sur les transitions Approve et Reject de Finance Review, avec respectivement Approved et Rejected.

Le même formulaire d'approbation peut être associé aux transitions Approve et Reject d'un nœud. Que le responsable approuve ou refuse, Spark ouvre d'abord le formulaire de transition correspondant et exige un avis. Une fois la validation réussie et la transition exécutée, Set Task Field écrit le résultat correspondant à la transition réellement choisie. Enfin, purchaseView présente en lecture seule les avis et les résultats.

Ne rendez pas un champ Result modifiable par l'approbateur sous forme de Select et ne vous appuyez pas uniquement sur un bouton de formulaire pour changer l'affichage. Le résultat doit être configuré dans Functions sur la transition correspondante afin que la valeur persistée corresponde toujours au chemin Approve ou Reject réellement exécuté.

Lors de la configuration des conditions, Validators et Functions, sélectionnez les champs proposés par l'éditeur. Ne copiez pas manuellement un Label ou un Field Key généré par le système, car la référence enregistrée pourrait ne pas être résolue ou affichée correctement par le Designer.

L'image suivante montre le workflow configuré :

Résultat attendu : après enregistrement, aucun nœud n'est déconnecté et chaque nœud de fin possède un chemin complet depuis Start.

Configurer le workflow avec Codex ou Claude Code

Si vous avez terminé l'installation et l'authentification de Spark CLI et installé l'intégration Codex ou l'intégration Claude Code, décrivez directement le workflow attendu à l'IA. Elle peut utiliser les commandes sémantiques de Spark CLI pour créer les nœuds, relier les routes, associer les Steps et les formulaires, puis configurer Conditions, Validators et Post Functions.

Précisez dans votre demande l'App cible, la version de conception, les nœuds, les conditions de branchement, les responsables, les formulaires de transition, les règles de validation et les règles d'écriture des champs. Par exemple :

Configure Purchase Approval dans la version DEVELOPING courante de spark-sample :
réutilise les Steps Department Review et Finance Review. Après l'approbation du
département, crée une branche selon Amount : approbation directe en dessous de 10000,
et Finance Review à partir de 10000. Termine en Rejected si l'une des approbations est
refusée. Associe managerReview et financeReview aux transitions correspondantes et
rends les avis obligatoires. Après Approve / Reject, écris le Review Result concerné
avec Approved / Rejected. Avant toute modification, affiche l'App, la version, le
workflow et la liste complète des changements. Attends ma confirmation, applique les
changements, puis exécute la vérification du workflow.

La configuration assistée par l'IA ne remplace pas la revue de conception. Avant de confirmer, vérifiez l'App, la version et le workflow cibles. Après les modifications, contrôlez la structure graphique dans Process Designer et validez les utilisateurs, autorisations, données d'organisation et branches dans l'environnement d'exécution approprié. Consultez Édition sémantique des workflows pour les commandes et un exemple complet.

5. Créer un schéma d'autorisation

Lors de la première configuration des autorisations, il n'est pas nécessaire de créer chaque règle à partir d'un schéma vide. Dans Data & Permission → Permissions, cliquez sur Import System Default pour copier un schéma d'autorisation par défaut modifiable :

Après l'import, ouvrez Configure et contrôlez les règles. Pour distinguer plusieurs types de tâche, utilisez Edit et renommez le schéma Purchase Request Permission. La capture de cet exemple conserve le nom importé Default Task Permission. Si vous avez déjà créé manuellement un schéma vide, ouvrez Configure et importez les mêmes règles par défaut depuis l'état vide.

Chaque ligne du schéma représente une règle Permission Item + Grant Type + Grant Parameter facultatif. Pour cet exemple, le schéma par défaut importé contient déjà les règles principales suivantes :

Permission Item	Grant Type	Rôle dans le workflow d'achat
Create Task	System User	Autorise les utilisateurs connectés à créer une demande d'achat
View Task	Task Creator	Autorise l'Applicant à consulter une demande qu'il a créée
View Task	Current Assignee	Autorise le Department Manager ou Finance Approver à consulter la tâche qui lui est affectée
View Task	Historical Assignee	Autorise un approbateur ayant déjà traité la tâche à continuer de la consulter
Transition Task	Current Assignee	Autorise uniquement le responsable courant à exécuter Approve, Reject et les autres transitions
Revoke Task	Task Creator	Autorise l'Applicant à retirer sa demande selon les règles du workflow
Log Work	Current Assignee	Autorise le responsable courant à saisir du temps ; ne contrôle pas Approve ou Reject

Il n'est pas nécessaire d'ajouter une autorisation System Role View Task ou Transition Task pour Finance Approver. Le rôle Finance Approver sert à affecter le nœud Finance Review dans le Workflow. Lorsqu'une demande de montant élevé entre dans ce nœud, l'utilisateur qui reçoit réellement la tâche devient Current Assignee et obtient automatiquement les droits de consultation et de transition du tableau. Accorder directement View Task à l'ensemble du rôle système Finance Approver permettrait à tous ses membres de consulter toutes les demandes d'achat associées à ce schéma, et pas uniquement celles de la branche de montant élevé.

Si l'Applicant doit pouvoir modifier la tâche après soumission, ajoutez Edit Task + Task Creator. La possibilité de modifier dans un statut donné doit aussi être contrôlée par le statut du workflow et les opérations disponibles. Les choix réels de Permission Item, Grant Type et Grant Parameter proviennent des extensions enregistrées dans le système courant ; sélectionnez-les toujours dans les propositions de l'interface.

6. Créer un Task Type

Ouvrez Task Configuration → Task Types et créez :

• Task Type Key : PURCHASE
• Task Type Name : Purchase Request
• Category : Procurement
• Default Workflow : Purchase Approval
• Permission Schema : sélectionnez le schéma vérifié à la section 5. La capture utilise Default Task Permission.
• Create Form : purchaseCreate
• View Form : purchaseView
• Edit Form : purchaseView

N'associez pas managerReview ou financeReview au Task Type. Ils sont déjà liés à des transitions précises du Workflow via Transition Form.

Résultat attendu : la liste Task Type affiche Purchase Request, le contrôle de complétude réussit et le workflow par défaut, le schéma d'autorisation et les trois emplacements de formulaire sont associés.

7. Vérifier la conception et choisir l'environnement de validation

Revenez dans Designer Overview, sélectionnez la version DEVELOPING courante et lancez le readiness check. Corrigez les problèmes bloquants tels que les nœuds déconnectés, les responsables manquants, les ressources non liées ou les autorisations incomplètes.

Après ce contrôle structurel, choisissez l'environnement adapté à l'étape courante :

• Pour une configuration rapide et un débogage individuel, ouvrez directement l'environnement d'exécution DEV et validez la version DEVELOPING courante. Ce démarrage rapide suit ce chemin et toutes les captures ci-dessous proviennent de DEV.
• Pour l'intégration en équipe, la recette formelle ou la validation avant mise en production, examinez les différences de ressources entre la version courante et celle publiée dans TEST, puis publiez dans TEST après confirmation. La publication dans TEST est facultative et ne constitue pas un prérequis pour terminer ce démarrage rapide.

Le readiness check détecte uniquement les problèmes structurels. Il ne remplace pas une validation avec de vraies données d'organisation, rôles, autorisations et données d'exécution. Si vous utilisez TEST, consultez Tests et publication pour les détails.

8. Valider dans DEV

La capture de cette section provient de DEV. Exécutez les scénarios suivants avec les utilisateurs de test préparés :

1. En tant qu'Applicant, créez une demande avec un Amount inférieur à 10000. Après approbation par Department Manager, la tâche doit passer directement à Approved.
2. En tant qu'Applicant, créez une demande avec un Amount supérieur ou égal à 10000. Après l'approbation du département, elle doit entrer dans Finance Review, puis passer à Approved après l'approbation de Finance Approver.
3. Créez une autre tâche et sélectionnez Reject à l'étape département ou finance. Vérifiez qu'elle passe à Rejected.
4. Avec Applicant, Department Manager et Finance Approver, contrôlez My Created, My Pending et les tâches traitées. Vérifiez que seuls les utilisateurs visés peuvent consulter et traiter chaque tâche.
5. Ouvrez purchaseView. Après chaque action Approve ou Reject, vérifiez que le Review Result correspondant affiche Approved ou Rejected et que l'avis contient le texte saisi par le responsable.

Critères de réussite : les tâches peuvent être créées dans DEV, les responsables sont correctement déterminés, les deux branches de montant et la branche de rejet fonctionnent comme prévu, et les formulaires, autorisations et résultats sont vérifiables. Si vous publiez dans TEST, répétez les mêmes scénarios dans TEST et contrôlez l'enregistrement de publication.

9. Étapes suivantes

• Configurer les champs en détail
• Comprendre le routage et les responsables
• Modifier les workflows avec Spark CLI
• Résoudre les problèmes d'exécution