Should creating an object in a process builder flow invoke before insert triggers?

Question

I have a process builder flow, invoked when an instance of a custom object, A__c, is created. This process builder flow creates an instance of another custom object B__c. This custom object B__c has a trigger.

It seems that the trigger on B__c (before insert/before update) is not being invoked.

I'm aware of the order of execution being that processes are executed at the end of the transaction lifecycle, after all triggers, but would expect A__c's lifecycle to kick the creation of the B__c instance which would then cause B__c's lifecycle to be executed separately. Isn't that the case?

Could it be that the process builder flow is causing both insert and update but only invokes the trigger on insert (before the value the trigger uses in its logic is set)? (I said above it isn't invoked, but I'm not sure if that is 100% true - what I can say is that the expected code path in the trigger isn't invoked and I need to try adding some debug output to see exactly what happens. I will update the question when I can.)

The process builder uses "Create a Record", setting a number of field values by copying data from the contextual object (i.e. the object for which the process builder flow was invoked).

Is this expected behaviour?

Answer 1

When one transaction event lifecycle, such as an update to an instance of custom object A__c, is processed, the process builder flow(s) defined for that event are invoked in the "Save procedure" after any triggers, as per the documentation:

4. Executes all before triggers.

then

8. Executes all after triggers.

then

14. Executes processes and flows launched via processes and flow trigger workflow actions.

The key documentation here is the note below step 14:

When a process or flow executes a DML operation, the affected record goes through the save procedure.

I.e., in this scenario the DML operation of "Create a Record" does indeed go through the same sequence and will invoke all triggers and other configured processing.

The apparent failure to invoke the trigger was actually due to incorrect data in the tested processing; the trigger wasn't seeing the expected data and so didn't go through the anticipated conditional logic.