+ Start a Discussion
asadimasadim 

Queuing Triggers to fire after Workflows

Hi,

 

We have some triggers on some object X, and then there are a couple Field Update Workflows on the same object that run after the triggers. These Workflows cause the same triggers to fire again because they update object X (as a result of Field Update). What I want to do is prevent this from happening. Is there a way to queue triggers to run after Workflows? An alternative method is perhaps using an intermediary static class to keep track of the triggers that have already run, but then I don't know if this class can keep its state after the Workflows start running.

 

Any help is appreciated!!

Rick_NookIndRick_NookInd

First, if you want workflows to trigger consistently, you should never do "Field Update" with any Workflows.  Instead the workflow would unfortunately need to be replaced with a trigger and a DML.  This is because of the bug.... err feature that Workflows can not trigger other Workflows.  There is an idea that you can vote on if you don't like this either.

 

Second, each time you update an object the trigger is supposed to fire.  Thats how they are supposed to work, and with the exception of a handful of circumstances thats how they do work.  You can not change the order of execution or prevent it.  You can have a static variable to detect how many times the trigger has been called in the transaction, but there would be no way to know if that is the last time only how many times it has been called in that transaction.

 

Here is what I suggest.  When I write a trigger, I try to write it "smart", i.e. to examine what is happening to determine what needs done.  For example, you could compare the old and the new values of the updated field to determine if this is indeed the kind of update in which the trigger code should run (i.e. only run if that certain field updated is updated).

 

 

TbomTbom

from the documentation on Execution Order:

11. If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time).

 

Note
The before and after triggers fire one more time only if something needs to be updated. If the fields have already been set to a value, the triggers are not fired again.
LVSLVS

Tbom wrote:

from the documentation on Execution Order:

11. If the record was updated with workflow field updates, firesbeforeandaftertriggers one more time (and only one more time).

 

Note
Thebeforeandaftertriggers fire one more time only if something needs to be updated. If the fields have already been set to a value, the triggers are not fired again.

Hi Tbom,

 

I know this is rather late. The documentation still says the same. What I never understood is (and that's how I reached here; search) what do they mean by "only if something needs to be updated" ? How does Salesforce "know" if "something" needs to be updated in my trigger?

 

~LVS

sfdcfoxsfdcfox

I know this is even later, but I'll put it here in case anyone needs to know.

 

When a workflow rule performs a field update, and that field update changes the field's value, then salesforce.com will execute the triggers for that record. That's basically what the "note" from the developer docs is talking about.

 

This has two implications:

 

1) Triggers that do something indiscriminately will double their effects. For example, if you have a trigger that increments a counter value, and a workflow rule causes a recursive trigger call, the counter's value will increase two increments instead of only one. A static variable can help eliminate this effect if it would cause an infinite loop or undesirable side effect (such as doubling a counter), as static values persist through an entire chain of triggers in the same transaction. When implication #2 (below) is put into play, static variables are in a separate transaction and thus will not retain the values from their original transaction.

 

2) Workflow rules can call triggers long after the original edit of the record. A time-based workflow rule that calls a field update will call the trigger when the update occurs, as if the user performed an edit at that time. This makes it possible to create self-sustaining loops, such as the classical scheduled apex class method that was independently devised by several developers, including myself, before the Schedulable interface was introduced.