top of page

Tout savoir de l'ordre d'exécution des processus Salesforce

Dernière mise à jour : 9 févr. 2023


La création de processus avec Salesforce est une tâche assez facile, mais si vous ne descendez pas sous la surface, vos processus peuvent finir par créer une dette technique involontaire dans votre système. Cela peut ralentir votre organisation ou, pire encore, vous pouvez commencer à trouver des erreurs fatales dues au dépassement des limites Salesforce.


Ordre d'exécution de Salesforce


Les solutions déclaratives, en no-code (Process builder, flow, workflows) et développées (Apex, Lwc) sont toutes intégrées dans l'ordre d'exécution et affectent le fonctionnement de votre système.


Que vous soyez administrateur, développeur ou architecte, gardez toujours à l'esprit la façon dont votre nouvelle solution affecte et interagit avec la fonctionnalité standard existante de l'org, les groupes gérés et les personnalisations existantes.


Ordre d'exécution de Salesforce
Ordre d'exécution de Salesforce

 

Ordre d'exécution à partir de l'API v54 de Developer Docs




Lorsque vous enregistrez avec une instruction d'insertion, de mise à jour ou d'upsert, Salesforce exécute les événements suivants dans l'ordre.


  1. Charger l'enregistrement original depuis la base de données ou initialiser l'enregistrement pour une instruction upsert.

  2. Charger les valeurs des champs du nouvel enregistrement à partir de la demande et écrasez les anciennes valeurs.

    1. Si la demande provient d'une page d'édition standard de l'interface utilisateur, Salesforce exécute une validation système pour vérifier l'enregistrement.

      1. La conformité avec les règles spécifiques au modèle.

      2. Les valeurs requises au niveau du modèle et de la définition des champs.

      3. Formats de validation des champs.

      4. La longueur maximale des champs.

    2. Lorsque la demande provient d'autres sources, comme une application Apex ou un appel API SOAP, Salesforce ne valide que les clés étrangères. Avant d'exécuter un déclencheur, il vérifie que les clés étrangères personnalisées ne font pas référence à l'objet lui-même.

    3. Salesforce exécute des règles de validation personnalisées si des éléments multilignes ont été créés, tels que des éléments de ligne de devis et des éléments de ligne d'opportunité.

  3. Exécuter les flux déclenchés par les enregistrements qui sont configurés pour s'exécuter avant que l'enregistrement ne soit sauvegardé.

  4. Exécuter tous les déclencheurs avant.

  5. Exécuter à nouveau la plupart des étapes de validation du système, en vérifiant par exemple que tous les champs obligatoires ont une valeur non nulle et en exécutant toutes les règles de validation personnalisées. La seule validation du système que Salesforce n'exécute pas une seconde fois (lorsque la demande provient d'une page d'édition d'interface utilisateur standard) est l'application de règles spécifiques à la mise en page.

  6. Exécuter les règles de duplication. Si la règle de duplication identifie l'enregistrement comme un duplicata et utilise l'action de blocage, l'enregistrement n'est pas sauvegardé et aucune autre étape (telle que les déclencheurs et les règles de flux de travail) n'est effectuée.

  7. Enregistrer l'enregistrement dans la base de données mais ne le validez pas tout de suite.

  8. Exécuter tous les déclencheurs ultérieurs.

  9. Exécuter les règles d'affectation.

  10. Exécuter les règles de réponse automatique.

  11. Exécuter les règles de flux de travail. S'il y a des mises à jour de champs de workflow :

    1. Metter à nouveau à jour l'enregistrement.

    2. Exécuter à nouveau les validations du système. Les règles de validation personnalisées, les flux, les règles de duplication, les processus et les règles d'escalade ne sont pas réexécutés.

    3. Exécuter les déclencheurs avant mise à jour et les déclencheurs après mise à jour, quelle que soit l'opération d'enregistrement (insertion ou mise à jour), une fois de plus (et seulement une fois de plus).

  12. Exécuter les règles d'escalade.

  13. Exécuter les automatisations Salesforce Flow suivantes, mais pas dans un ordre garanti.

    1. Processus

    2. Flux lancés par des processus

    3. Flux lancés par des règles de workflow (pilote d'actions de workflow de déclenchement de flux).

    4. Lorsqu'un processus ou un flux exécute une opération DML, l'enregistrement concerné passe par la procédure de sauvegarde.

  14. Exécuter les flux déclenchés par l'enregistrement qui sont configurés pour s'exécuter après l'enregistrement.

  15. Exécuter les règles d'habilitation.

  16. Si l'enregistrement contient un champ récapitulatif ou fait partie d'un flux de travail inter-objets, effectuer des calculs et mettre à jour le champ récapitulatif dans l'enregistrement parent. L'enregistrement parent est soumis à une procédure de sauvegarde.

  17. Si l'enregistrement parent est mis à jour et qu'un enregistrement grand-parent contient un champ récapitulatif récapitulatif ou fait partie d'un workflow inter-objets, le système effectue des calculs et met à jour le champ récapitulatif récapitulatif de l'enregistrement grand-parent. L'enregistrement grand-parent passe ensuite par la procédure de sauvegarde.

  18. Exécuter l'évaluation du partage basé sur des critères.

  19. Valider toutes les opérations DML dans la base de données.

  20. Après que les changements ont été validés dans la base de données, la logique post-commit est exécutée.

    1. Voici quelques exemples de logique post-commit (sans ordre particulier) :

      1. L'envoi d'un courriel

      2. L'envoi d'un courriel synchrones mis en file d'attente, y compris les travaux pouvant être mis en file d'attente et les méthodes futures.

      3. Chemins asynchrones dans les flux déclenchés par des enregistrements


 


Considérations supplémentaires




Notez ce qui suit lorsque vous travaillez avec des déclencheurs.



  • Si la mise à jour d'un champ d'une règle de workflow est déclenchée par la mise à jour d'un enregistrement, Trigger.old ne contient pas le champ nouvellement mis à jour par le workflow après la mise à jour. Au lieu de cela, Trigger.old contient l'objet avant la mise à jour initiale de l'enregistrement. Par exemple, un enregistrement existant possède un champ numérique dont la valeur initiale est 1. Un utilisateur met à jour ce champ à 10, et une mise à jour de champ de règle de workflow se déclenche et l'incrémente à 11. Dans le déclencheur de mise à jour qui se déclenche après la mise à jour du champ du workflow, la valeur du champ de l'objet obtenue à partir de Trigger.old est la valeur initiale de 1, et non 10. Voir les valeurs de Trigger.old avant et après les déclencheurs de mise à jour.


  • Si un appel DML est effectué avec un succès partiel autorisé, les déclencheurs sont déclenchés lors de la première tentative et sont à nouveau déclenchés lors des tentatives suivantes. Comme ces invocations de déclencheurs font partie de la même transaction, les variables de classe statiques auxquelles le déclencheur accède ne sont pas réinitialisées. Voir Traitement des exceptions DML en masse.


  • Si plus d'un déclencheur est défini sur un objet pour le même événement, l'ordre d'exécution du déclencheur n'est pas garanti. Par exemple, si vous avez deux déclencheurs before insert pour Case et qu'un nouvel enregistrement Case est inséré. L'ordre d'exécution de ces deux déclencheurs n'est pas garanti.


  • Si un objet possède plusieurs flux actifs déclenchés par des enregistrements qui sont configurés pour s'exécuter avant ou après l'enregistrement, l'ordre d'exécution de ces flux n'est pas garanti.


  • Pour en savoir plus sur l'ordre d'exécution lorsque vous insérez un contact non privé dans votre org qui associe un contact à plusieurs comptes, consultez "AccountContactRelation".


  • Pour en savoir plus sur l'ordre d'exécution lorsque vous utilisez des déclencheurs avant pour définir le stade et la catégorie de prévision, voir " Opportunité".









0 commentaire

Comments


Commenting has been turned off.
bottom of page