How can I know if it's the last execution of an After Trigger?

Question

Imagine one object with 20 fields, field1 to field20. Some of these fields I have Process Builder in place, some of them I have Worflow Updates, and some of them are 'bare field' (i.e. PB and WF does not touch it).

My problem is that, depending on the operation that the record performs, these tools (PB and WF) are fired or not, and it implies in how many times the After Trigger is fired.

• If the operation performed is 'clean' (i.e. it will not fire WF or PB), the After Trigger fires only once.

• If the operation causes a WF to fire, the After Trigger fires twice.

• If the operation causes a WF and PB to fire, the After Trigger fires three times.

I need to execute certain things only on the last time that the After Trigger fires.

Is it possible to isolate it without getting rid of the current PB and WF implementation?

Answer 1

Conceivably what you could do is set up a Queueable class. On the first pass through the trigger, instantiate and enqueue it, and then save that in a static variable so you know it's already been created. It will run once after all executions are done, in a separate transaction.

The trouble is, once you have enqueued it, you can no longer alter any data you've passed into that instance. But if you need to alter such data, what you could do is either a) store the extra data it needs to pick up somewhere in the database, indexed to the job ID retrieved when it was enqueued, or b) cancel the job (delete the AsyncApexJob) and enqueue it again with the new data added to it.

Downside of b) is that each time you enqueue it counts against the limit of how many jobs can be enqueued in one transaction, even if you later dequeue it.

Answer 2

AFAIK there is no way to do this without adding explicit logic. And that explicit logic is pretty ugly e.g. make the WF and PB set database data or static variables that signal they have run and then have the trigger check those. Which couples the pieces together horribly.

If possible, write the trigger so it is idempotent i.e. nothing bad happens even if it does run multiple times, so the problem goes away.

Answer 3

It sounds like you are looking for an exit event. If doesn't exist yet, but you can vote for the idea, the description of which is pasted below:

Since triggers only handle 200 records at a time, it would be convenient if we could schedule some code that runs in the same transaction as the current transaction, but after all other triggers, recursion, etc has executed. The registration function could be called repeatedly, but would only execute once at the end of the transaction. Here's some code that demonstrates this interface:

public class MyAfterEverythingElseHandler implements System.AtExitHandler {
     public void atExit() {
          // Perform some cleanup. For example, perform one last DML, send emails regarding the transaction, etc.
     }
 }

The class only triggers if called at least once through System.atExit, such as:

System.atExit(MyAfterEveryElseHandler.class);

This is similar to the @future annotation, but doesn't spawn a new process, has access to the full static environment of the current transaction, and remains subject to the governor limits of the current transaction. Multiple handlers could be registered via this mechanism, but the calling order would be undefined.

Typical uses might be to aggregate together a @future call on many thousands of records at once, debug logging, aggregate email sends across triggers, etc. Ideally, this interface should restrict DML operations, perhaps calling a "plain" commit for any records modified during the handler (e.g. no triggers, workflow rules, etc), or disabled completely, but could still call @future methods, System.executeBatch, System.scheduleBatch, and System.schedule.