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
OldDeadBugOldDeadBug 

Distinguishing Before-Workflow triggers and After workflow triggers??

I know we have options for:

trigger.isBefore
trigger.isAfter
trigger.isInsert
trigger.isUpdate
trigger.isDelete
trigger.isUpsert

but is there a way to distinguish in the trigger whether it is before or after the Workflow has been evaluated, such as

trigger.isBeforeWorkflow
trigger.isAfterWorkflow

Would this be a good idea?
werewolfwerewolf

Execution order is fixed -- there is no "before workflow" and "after workflow."

 

The docs on execution order say (emphasis is in the original document, I didn't add it):

 

The following is the order salesforce logic is applied to a record.

  1. Old record loaded from database (or initialized for new inserts)
  2. New record values overwrite old values
  3. All Apex “before” triggers (EE / UE only)
  4. System Validation Rules
  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)

Additional notes:


There is no way to control the order of execution within each group above.

 

Workflow field updates that run based on an approval process or time-dependent action do not trigger any rules.

 
OldDeadBugOldDeadBug
I believe this has recently changed with the critical update. The APEX Developer Guide now reads as follows-please note lines 9 - 11 separated below. I would outline them in bold lettering, but the Edit as HTML button isn't working

1. Loads the original record from the database or initializes the record for an upsert statement.
2. Loads the new record field values from the request and overwrites the old values. If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
* Compliance with layout-specific rules
* Required values at the layout level and field-definition level
* Valid field formats
* Maximum field length
Salesforce does not perform system validation in this step when the request comes from other sources, such as an Apex application or a Web Services API call.
3. Executes all before triggers.
4. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce does not run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
5. Saves the record to the database, but does not commit yet.
6. Executes all after triggers.
7. Executes assignment rules.
8. Executes auto-response rules.

9. Executes workflow rules.
10. If there are workflow field updates, updates the record again.
11. If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time).

12. Executes escalation rules.
13. If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record.
14. Commits all DML operations to the database.
15. Executes post-commit logic, such as sending email.


So, before and after triggers now run twice, before and after workflow rules are evaluated and field updates are implemented.
cgosscgoss

We just ran into the following problem, which I think is a bug:

 
Consider the following scenario:

 - Trigger on beforeUpdate on the Contact object
 - Workflow rule and Field update task on Contact object

 

1. When a change is made to a contact record, the trigger will fire and correctly pass both the new values (Trigger.new) and previous values (Trigger.old) to the Apex code in the beforeUpdate trigger.

 

2. After all triggers (before and after) are complete, the platform executes the workflow rule that updates a field on the same Contact record.

 

3. The trigger is executed again, passing in EXACTLY the same values for Trigger.new and Trigger.old as the first execution of the trigger (before the WF rule).


What we'd expect is that the new and old values would be updated to reflect changes that happened in the previous trigger executions and workflow field updates. Neither is the case. This is creating quite a problem with rollup values and other data that we'd only expect to run once per update/insert.

 

I know of some workaround with static vars and such, but to all the members of our team, this is totally unexpected to get the same new/old values back in the second (post WF rule) execution of triggers.

Message Edited by cgoss on 05-22-2009 08:54 AM
rmolekillarmolekilla

what i would like to see is to be able to set an order between triggers of the same schedule group;
 
 
trigger A(before insert, before update)
...
trigger B(before insert, before update, after A)
 
of course, loops in the execution order should be resolved at compile/script validation time
 
 
right now i don't see any mechanism in place to establish/know the order several triggers must run, besides running and seeing which one runs first!
Message Edited by rmolekilla on 05-30-2009 11:00 AM
mikecaimikecai

This may be an old thread but I am running into the exact same situation.  A field update workflow rule is causing an after update trigger to fire twice, both times with the same Trigger.old and Trigger.new values.  I'm going to keep searching these forums for a solution, but if anyone has any ideas on how to handle this, please feel free to let us know!

 

Thanks! 
Tal One1Tal One1

This is still an issue.

Unbelievable Salesforce haven't fixed this yet!
Leandro Fernandes 12Leandro Fernandes 12

On the documentation: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm

It says about this "bug" aforementioned.

>>>>>>>

- Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger doesn’t contain the version of the object immediately before the workflow update, but the object before the initial update was made. For example, suppose that an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

<<<<<<<<

Even though, I am facing quite a challenge to catch the trigger at the right moment.