Alternatives to Static Booleans to Prevent Recursion

Question

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

Answer 1

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.