7

So using static booleans to prevent recursion has it's limitations, I recently found an issue with time based workflow:

In case they fire independently–Ensure that your Apex logic is scoped for a single scheduled action. For example, don't use Apex static variables to communicate state across Apex code triggered by different scheduled actions.

Taken from this help article

I get a proper trigger framework is the best long term solution but what other alternatives are there? Would adding record ids to a processed set and checking against this work? Something like:

public Class processedIdClass{
    public set<Id> processedIds = new Set<Id>();
}

Some further background - but I don't want to distract too much from my question. Would the set of Ids approach work in this context?

To prevent recursion I have used the well known static boolean method (e.g stop duplicates records being created). The help article I linked to states:

Apex triggers that fire as a result of time-dependent actions may get executed in a single batch or independently.

The latter rendering the static boolean unusable as the first record sets it...then the other records being processed in the same 15 minute period aren't processed as the flag as already been. Here's the execute anon scripts that exhibit the same behavior (with the assumption that our static boolean is on the Account trigger):

Bulk, behaves as expected

List<Account> allAccounts = List<Account>([SELECT Id FROM Account limit 100]);
update allAccounts;

independently

update account1; //will be updated and sets boolean flag
update account2; //won't be updated as flag already set
update account3; //won't be updated as flag already set
  • You may have your terms mixed up (or I do) which makes the question difficult to understand what you are trying to get at. Recursion only happens during the same execution context. Static booleans to prevent recursion are not used to communicate across transactions. What is it you are trying to prevent, multiple TB WFR's on the same record? – Eric Sep 3 '16 at 20:31
  • @Eric I have added further detail to the question. My issue fundamentally is the bulkification (or lack of) for records processed in the same 15 minute period for time based workflow. – Girbot Sep 3 '16 at 21:15
  • 1
    Yeah that's not recursion. You have entirely separate transactions you're trying to apply this logic to. – Adrian Larson Sep 4 '16 at 14:48
3

Easiest way I can think of to do what your are trying to would be as follows:

  • Keep in mind you may have to modify this a bit as I am not entirely clear on what you are trying to accomplish (If it is all records or a single record)

    1. Create a Date/Time field on the object / Custom setting
    2. When an event happens that needs to be processed check the time/date field
    3. If more than 15 mins ago do the process and set the time/date to now
    4. If not more than 15 minutes ago exit

Again, it all depends on if this is a single records based time limit or an object based time limit.

If you have no code then you can use the value of the time.date field to make decisions in your workflow as well.

  • Steps 3-4 should probably have the same interval? – Adrian Larson Sep 6 '16 at 0:54
  • I like this solution. I might just go with a List Custom Setting where the name contains the Id of any record that's been updated through this process and then look only at records created within the last 15 minutes, but it's pretty similar and, as you say, depends on the specific requirements. – Adrian Larson Sep 6 '16 at 1:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.