Modernisation des Flows Salesforce
Les modèles par défaut utilisent les motifs de Flow de leurs données d'entraînement : Boucle + Décision + Assignation, DML à l'intérieur des boucles, mises à jour après enregistrement de l'enregistrement déclencheur, écrans supplémentaires pour recalculer. Ce skill les remplace par les éléments actuels et vous fournit des métadonnées vérifiées par déploiement pour chacun dans examples/.
Ces règles déterminent la plupart des décisions :
- L'élément moderne est la valeur par défaut. Une Boucle nécessite une condition d'échappement déclarée (ci-dessous). Lorsque le XML d'un élément est inconnu, copiez la forme de son fichier d'exemple au lieu d'éviter l'élément.
- Non vérifiable ne signifie pas indisponible. La disponibilité suit la version API de l'org et le tableau ci-dessous. Vous n'avez pas besoin d'un accès web pour utiliser un élément dont le minimum est inférieur ou égal à la version de l'org. La validation de déploiement est le contrôle.
- Chaque boucle et chaque repli sont expliqués. Nommez l'échappement dans la description de la Boucle et dans le livrable. Sans échappement nommé, n'écrivez pas la boucle.
Flux de travail
Copiez cette liste de contrôle dans vos notes de travail et cochez-la :
- [ ] 1. Lire references/org-conventions.md ; lister les emplacements non définis dont cette tâche dépend
- [ ] 2. Établir la version API de l'org
- [ ] 3. Classifier la tâche : construction, audit ou migration ; type de Flow, événement déclencheur, exécution par qui
- [ ] 4. Cartographier chaque exigence à travers la table de décision ; ouvrir chaque exemple que vous utilisez
- [ ] 5. Écrire les métadonnées (ou la spécification de construction)
- [ ] 6. Exécuter scripts/check-flow.mjs ; corriger chaque ERREUR, décider chaque AVERTISSEMENT
- [ ] 7. Valider le déploiement lorsqu'un org est disponible ; sinon étiqueter le XML comme non validé
- [ ] 8. Exécuter la liste de contrôle d'examen dans references/delivery.md et livrer
Étape 1. Conventions. Un emplacement rempli dans org-conventions.md prime sur les valeurs par défaut de ce skill. Un emplacement vide signifie que la valeur par défaut s'applique et le livrable le liste sous décisions ouvertes.
Étape 2. Version API. Avec un org, sf org display --target-org <alias> affiche "Api Version". Sans org, utilisez sourceApiVersion du sfdx-project.json du projet, ou 67.0 si celui-ci est également manquant, et dites-le. Définissez le apiVersion des nouveaux Flow sur cette version.
Étape 3. Classifier. Flow existant ou nouvelle construction. Type de Flow (écran, déclenché par enregistrement avant ou après enregistrement, lancé automatiquement, déclenché par planification, déclenché par événement de plateforme). Objet déclencheur et événement déclencheur, répondus à partir de l'exigence avant d'ouvrir un exemple. La question est de savoir si un enregistrement créé répondant déjà à la condition compte, ou seulement un qui change pour y répondre. Créer et mettre à jour avec "uniquement lorsque mis à jour pour répondre à la condition" se déclenche lors d'une telle création, tandis que mise à jour uniquement ne le fait pas. Si l'exigence ne le dit pas, demandez ou indiquez l'hypothèse (record-triggered.md). Qui l'exécute (utilisateur, système, agent). Ce qui doit se produire de manière synchrone. Pour les Flows d'écran, la surface qui l'incorpore et ce qu'il prend et retourne.
Étape 4. Cartographier. Pour chaque opération de collection, liste de choix, interaction d'écran, mise à jour d'enregistrement, besoin de synchronisation et intégration, prenez la ligne du tableau de décision. Lisez le fichier d'exemple pour chaque élément que vous allez écrire, et la référence de domaine pour ses limites. Lisez uniquement les références pour les domaines que la tâche touche.
Étape 5. Écrire. Les métadonnées vont dans force-app/main/default/flows/<ApiName>.flow-meta.xml (ajustez au répertoire de package du projet). Conventions de nommage : noms API de Flow Objet_Verbe_Condition, noms d'éléments Type_But (Get_Open_Cases, Filter_High_Priority, Transform_To_Tasks, Dec_Is_Renewal), sauf si org-conventions.md dit autrement. Définissez <status>Draft</status> sauf si l'utilisateur demande explicitement un Flow actif ou que l'emplacement de la politique d'activation le dit. Les exemples sont Actifs uniquement parce qu'ils ont été exécutés. Gardez tous les éléments d'un même type ensemble dans le fichier (les groupes divisés échouent au déploiement). Sans accès CLI, livrez une spécification de construction au format dans delivery.md.
Étape 6. Vérifier. Exécutez le vérificateur sur chaque Flow que vous avez écrit ou qu'on vous a demandé de réviser. Il nécessite uniquement Node :
node <skill-dir>/scripts/check-flow.mjs --api <org-api-version> force-app/main/default/flows/<ApiName>.flow-meta.xml
Les ERREURS sont des motifs hérités ou des formes que la plateforme rejette, corrigez-les. Les AVERTISSEMENTS nécessitent une décision, que vous indiquez dans le livrable.
Étape 7. Valider. Avec un org authentifié, nommez l'org explicitement au lieu de vous fier à l'org par défaut de la CLI :
sf project deploy validate --source-dir force-app/main/default/flows/<ApiName>.flow-meta.xml --target-org <alias>
Corrigez en fonction de l'erreur exacte et réexécutez. Le XML qui n'a pas été validé est étiqueté comme non validé dans le livrable, clairement.
Étape 8. Réviser et livrer. Exécutez la liste de contrôle d'examen dans delivery.md. Terminez le livrable par ce bloc, chaque ligne remplie :
Mode : métadonnées | spécification de construction
Vérificateur : <commande> → <n> erreurs, <n> avertissements (<décision par avertissement>)
Validation de déploiement : <commande et résultat> | non exécutée, non validée (<raison>)
Statut : Brouillon | Actif (<pourquoi>)
Contexte d'exécution : <runInMode ou défaut, et ce que cela signifie pour ce type de Flow>
Échappements : <E-id et raison par boucle ou repli> | aucun
Décisions ouvertes : <emplacements de convention non définis dont ce Flow dépend> | aucun
Valeurs par défaut du contexte d'exécution (runInMode DefaultMode) : les Flows déclenchés par enregistrement, déclenchés par planification et déclenchés par événement de plateforme s'exécutent dans le contexte système sans partage. Les Flows d'écran et lancés automatiquement s'exécutent dans le contexte utilisateur lorsqu'ils sont lancés depuis l'interface utilisateur ou l'API REST, et dans le contexte de l'appelant lorsqu'ils sont appelés depuis Apex ou un autre Flow. Lancé automatiquement n'est pas "système par défaut".
Audits et migrations
Pour un Flow existant, exécutez d'abord le vérificateur dessus, puis inventoriez les motifs hérités restants par rapport à la dernière colonne du tableau de décision. Livrez le rapport d'audit défini dans delivery.md avant toute réécriture, classé par impact : limites de gouverneur, puis contexte de sécurité, puis expérience utilisateur. Ne modifiez pas le Flow sauf demande. Lorsqu'on vous le demande, suivez l'ordre du plan de migration du rapport. Décrivez les motifs, jamais les personnes qui les ont construits, car la plupart des motifs hérités étaient l'approche recommandée lorsqu'ils ont été écrits. Le mappage de Process Builder et des règles de workflow se trouve dans legacy-migration.md.
Table de décision
"Org API" est la version API d'org la plus basse qui possède l'élément (Guide du développeur Flow et API Metadata). Les exemples se trouvent dans examples/flows/, déployés et exécutés sur l'API 67.0.
| Besoin | Utiliser | Métadonnées | Org API | Exemple | Remplace |
|---|---|---|---|---|---|
| Conserver les éléments d'une collection qui correspondent aux critères | Collection Filter (conditions ou formule) | collectionProcessors, FilterCollectionProcessor | 53 | Opportunity_Create_Followup_Tasks | Boucle + Décision + Assignation |
| Construire des enregistrements à partir d'une collection, remodeler les champs | Transform, Map | transforms | 59 | Opportunity_Create_Followup_Tasks | Boucle + Assignation construisant une collection |
| Sommer ou compter une collection | Transform, Sum / Count. Dans les Flows avant enregistrement, Filter + Assignation AssignCount, ou une Boucle pour un Sum (E3) | transforms, inputParameters | 59 (cible primitive 62) | Opportunity_Create_Followup_Tasks, Account_Before_Save_Count_Contacts | Compteurs de boucle |
| Combiner deux collections par une clé | Transform, InnerJoin, avec le mappage dans le même Transform | transforms, JoinDefinition | 63 | Opportunity_Create_Account_Tasks_Joined | Boucles imbriquées, Get Records à l'intérieur d'une boucle |
| Ordonner une collection | Collection Sort (trie sur place) | SortCollectionProcessor | 50 | Opportunity_Allocate_Budget_Waterfall | Tri manuel dans une boucle |
| Créer, mettre à jour ou supprimer de nombreux enregistrements | Un DML sur la collection préparée | recordCreates inputReference | any | Opportunity_Create_Followup_Tasks | DML à l'intérieur d'une boucle |
| Options à partir d'enregistrements ou d'une liste de choix | Jeu de choix d'enregistrement / de liste de choix | dynamicChoiceSets | any | Account_Order_Entry_Screen | Get Records + Boucle construisant des choix |
| Totaux, visibilité ou texte qui suivent la saisie | Formule réactive, visibilityRule | formulas, champs d'écran | 59 | Account_Order_Entry_Screen | Un deuxième écran pour recalculer |
| Règles de saisie sur un écran | validationRule du composant | champs d'écran fields | any | Account_Order_Entry_Screen | Décision après l'écran de retour vers un écran d'erreur |
| Logique serveur sans quitter l'écran | Action d'écran + Bouton d'action | screens.actions, triggers | 59 | Account_Check_Pipeline_Screen | Suivant, Get Records, retour en arrière |
| Définir des champs sur l'enregistrement déclencheur | Flow avant enregistrement, Assignation à $Record | triggerType RecordBeforeSave | any | Opportunity_Before_Save_Set_Next_Step | Mise à jour après enregistrement des enregistrements sur $Record |
| Bloquer une sauvegarde avec un message | Erreur personnalisée | customErrors | 59 | Opportunity_Before_Save_Set_Next_Step | Compensation après enregistrement |
| S'exécuter uniquement lorsque les champs pertinents changent | Conditions d'entrée, filterFormula avec ISCHANGED, "uniquement lorsque mis à jour pour répondre à la condition" | start | 55 (formule) | Opportunity_Before_Save_Set_Next_Step, Opportunity_Closed_Won_Handover | Décision comme premier élément |
| Appels, e-mails, DML non liés pour lesquels l'utilisateur n'a pas besoin d'attendre | Chemin asynchrone | scheduledPaths AsyncAfterCommit | 53 | Opportunity_Closed_Won_Handover | Tout synchrone |
| Travailler avant ou après une date d'enregistrement | Chemin planifié | scheduledPaths RecordField | 51 | Opportunity_Closed_Won_Handover | Flow déclenché par planification interrogeant les enregistrements dus |
| Réagir à un événement de plateforme | Flow déclenché par événement de plateforme | triggerType PlatformEvent | 49 | Order_Event_Create_Task | Déclencheur Apex écrit pour démarrer la logique Flow |
| Pause jusqu'à l'arrivée d'un événement | Élément Wait avec un événement de plateforme | waits | any | Order_Wait_For_Confirmation | Interrogation |
| Logique Flow pour un agent Agentforce | Flow lancé automatiquement avec des entrées et sorties décrites | variables description | any | Case_Get_Status_For_Agent | Wrapper Apex invocable |
| Ordre entre les Flows sur un seul objet | Ordre de déclenchement | triggerOrder | 54 | Opportunity_Closed_Won_Handover | Se fier à l'ordre de création |
| Appeler une API REST | Action d'appel HTTP | actionCalls (généré par Builder) | voir la référence d'intégration | aucun | Apex écrit uniquement pour l'appel |
Transform n'est pas autorisé dans les Flows avant enregistrement (erreur de déploiement). Avant enregistrement prime sur Transform, donc une valeur sur l'enregistrement déclencheur reste avant enregistrement, et un Sum y est une Boucle sous E3, jamais un Transform après enregistrement plus une deuxième sauvegarde. Tout le reste ci-dessus fonctionne dans chaque type de Flow qui a le concept, et les références de domaine listent les exceptions.
Conditions d'échappement
Un motif hérité est correct uniquement lorsque l'une de ces conditions s'applique. Déclarez-le dans la <description> d'une Boucle comme Escape : E<n> <raison>, et dans le livrable.
| Id | Permet | Tient uniquement lorsque |
|---|---|---|
| E1 | Une Boucle | Chaque élément a besoin de son propre appel à une action, un sous-Flow ou un plugin Apex qui n'accepte que des valeurs uniques. Le corps de la boucle contient cet appel. |
| E2 | Une Boucle | Le résultat d'un élément dépend d'éléments antérieurs au-delà d'une somme ou d'un nombre : un solde courant, une allocation, un numéro de séquence, un round robin. |
| E3 | Une Boucle | Un Flow avant enregistrement a besoin d'un Sum (Transform n'y est pas autorisé). Ceci est délibéré, car la Boucle en mémoire est moins coûteuse qu'une deuxième sauvegarde après enregistrement. Les comptages utilisent Filter + AssignCount à la place. |
| E4 | Travail sur le chemin synchrone | Un élément ultérieur dans la même transaction lit le résultat, ou l'utilisateur doit le voir avant la fin de la sauvegarde. |
| E5 | Aucune fonctionnalité réactive ou d'écran plus récente | La surface d'incorporation nommée ne les prend pas en charge : runtime Salesforce Classic, Slack (ensemble de composants limité), ou un composant que la documentation réactive liste comme non réactif. |
| E6 | Laisser un motif hérité en place | Périmètre d'audit uniquement : le Flow est en dehors du changement que vous deviez apporter. Ne s'applique jamais aux Flows nouveaux ou réécrits. |
Ce qui suit ne compte pas comme conditions d'échappement :
- "Je ne peux pas vérifier que l'élément existe dans cet org" (la règle 2 s'applique, vérifiez donc la version API, puis validez le déploiement).
- "Je ne suis pas sûr du XML" (copiez l'exemple).
- "Une boucle est plus simple ou plus claire."
- "Valeurs conditionnelles par élément" (utilisez
IF()dans une formule Transform). - "Filtrer et mapper en un seul passage" (Filter, puis Transform).
- "La surface pourrait ne pas le prendre en charge" (nommez la surface ou listez-la comme décision ouverte, car une surface inconnue n'est pas E5).
- DML ou Get Records à l'intérieur d'une boucle. Aucun échappement ne les autorise.
Utilisez l'élément le plus simple suffisant. Cela signifie Filter seul lorsqu'il s'agit uniquement de filtrer, des choix statiques lorsque la liste d'options est fixe, et aucun sous-Flow pour une logique avec un seul appelant.
Vérifier avant d'affirmer
- Disponibilité : version API de l'org par rapport au tableau. Traitez les fonctionnalités limitées par licence (Agentforce, Einstein, Data 360, certaines éditions d'orchestration) comme des hypothèses jusqu'à ce que l'org les confirme, et dites-le.
- Limites et statut GA qui modifient une conception ou un résultat d'audit : citez la source officielle (help.salesforce.com, developer.salesforce.com). Ne citez pas de chiffres de mémoire, car les références de domaine donnent ceux vérifiés.
Gestion des erreurs
- CLI manquante ou org inaccessible : livrez des métadonnées étiquetées non validées, ou une spécification de construction, et dites lequel.
- La validation échoue : corrigez en fonction du message exact, réexécutez le vérificateur et la validation. Les références de domaine listent les erreurs de déploiement rencontrées jusqu'à présent.
- Fonctionnalité absente de l'org (version API, édition, licence) : utilisez la ligne prise en charge la plus proche du tableau, nommez l'écart et l'échappement.
Références
Lisez celles dont la tâche a besoin :
- org-conventions.md : les décisions de l'équipe, qui priment sur les valeurs par défaut.
- collections.md : Filter, Sort, Transform (map, sum, count, join), DML en masse, boucles.
- screens.md : jeux de choix, écrans réactifs, validation, actions d'écran, incorporation.
- record-triggered.md : événements déclencheurs, conditions d'entrée, ordre de déclenchement, avant vs après enregistrement,
$Record, erreurs personnalisées. - events.md : événements de plateforme, Wait, chemins planifiés.
- integration.md : appels REST, actions Apex, actions de sous-Flow, actions d'agent.
- limits.md : limites de gouverneur et de conception pour chaque élément moderne.
- legacy-migration.md : Process Builder, règles de workflow.
- delivery.md : format du livrable et liste de contrôle d'examen finale.
Skill basé sur les exemples et scripts dans examples/ et scripts/.