function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Austin_SteveAustin_Steve 

Is there an order of operations that workflows follow?

If I have multiple workflows on a single object is there a way I can guarantee one will happen before another? For example when the stage changes to Closed Won,  I would like a field on the opportunity object to get updated (using a workflow) before the email gets sent out (also using a work flow).

James CarboneJames Carbone

I believe the order will always be in the order in which you created the workflows.  The oldest runs first, latest runs last.  I've tried this out and it seems to hold true.  The same is true when you have many immediate workflow actions.  

 

I don't see this documented explicitly and therefore I would not bet that this will always be the case.  However I did see a tutorial from Salesforce showing how to solve this similar scenario by creating an update field action followed by an email action. 

 

To insure order you could create a trigger that uses apex that updates the object and then sends a notification.
sfdcfoxsfdcfox

The order of saving a record is as follows (per the Help & Training solution "In what order are automation rules and Apex triggers processed?"):

 

  1. Old record loaded from database (or initialized for new inserts)
  2. New record values overwrite old values
  3. System Validation Rules
  4. All Apex “before” triggers (EE / UE only) 
  5. Custom Validation Rules
  6. Record saved to database (but not committed)
  7. Record reloaded from database
  8. All Apex “after” triggers (EE / UE only)
  9. Assignment rules
  10. Auto-response rules
  11. Workflow rules
  12. Escalation rules
  13. Parent Rollup Summary Formula value updated (if present)
  14. Database commit
  15. Post-commit logic (sending email)
Changes made by one workflow rule will not be seen by any other workflow rule within the same execution unit. This is done to prevent the infinite recursion scenario (Rule A updates a field that triggers Rule B that updates a field that triggers Rule A...).
However, time-delayed workflow rules will trigger Apex Triggers normally, and that can cause workflow rules to be re-evaluated at a later time. We used this technique to implement Scheduled Apex before such a feature formally existed. You can conceivably determine the order of workflow rules by having two rules update the same field. The winner was the rule that executed last, so you can determine the order.
You can prove that both rules saw the same original data by using this example setup:
Rule 1: Criteria: Field A equals "yes", Actions: Field Update Field A to formula "no".
Rule 2: Criteria: Field A equals "yes", Actions: Field Update Field B to formula "Rule 2 ran".
Create rule 1 first (remember, they're supposed to execute based on creation order, and I have little reason to suspect otherwise), and then create rule 2. Rule 2 will fire, even though rule 1 performed an update that should have prohibited rule 2 from running.
From my previous observations, Salesforce seems to perform each step above as two steps:
1) Evaluate all records in the transaction to see if the criteria matches.
2) For each record matched in 1, carry out the associated actions.
This means that, irrespective of changes made by a step, no other rule in that step will see the changes made. This prevents the uncertain data scenario that you've described (as in, how do we determine if a rule will execute on a record). Multiple field updates on a record are processed by the order in which the rules (not the updates) were created.
For performance reasons, you should simply collapse the two rules into one rule, and assign the email and field update on the same rule. The email template should see all the changes made by all prior steps, since it appears to run a retrieve command for all associated records (because it might not have all the information available in memory anyways).