2

Currently doing some additional research for a process builder issue I was having a while ago, so I don't have the specific example here unfortunately.

The issue was due to the advanced process builder option "execute the actions only when specified changes are made" and not working exactly as expected. Solved the issue by putting an "object created" checkbox on the record that gets checked in the actions of the node and including criteria that the checkbox is unchecked.

But, just want to see if anyone knows more about how this option works.

All the documentation I can find is simply re-stating the help text: When you select yes, the actions are executed only if the record meets the criteria now but the values that the record had immediately before it was saved didn't meet criteria. This means that these actions won't be executed when irrelevant changes are made.

My question is if anyone knows how this before/now is evaluated. My best guess is that it's running the criteria through the "Trigger.Old" record and requiring that it was false entering in and true in the "Trigger.New" record.

Mostly just asking to satisfy my curiosity. Anyone have other thoughts on this?

2
  • 2
    Be aware there's a critical update (got pushed to Jun 2021) so that process builders evaluate records as their original values (how they came in and not based on updates you make within the same PB). Your checkbox scenario sounds like you're updating it in one node to affect another criteria. May 5 '20 at 16:23
  • @Kris Goncalves -- Man I think this might be it! Thank you so much mate. Going to do one last test to see if this hits it. For the record, thinking that with the critical update on it might actually be causing the unexpected recursion. May 6 '20 at 21:09
3

This works exactly like the Trigger.old vs Trigger.new principle. When a field has a different value before the update vs. after the update in a specified field, only then the process will execute. When it's a new record, obviously there are no values for the old version (there's no old version at all), so any value in the field would be considered a change, and invoke the process actions.

1
  • Yep - thanks EranV. I did some testing trying to replicate the weirdness I was seeing that prompted this question and can confirm that this appears to be the case. (Failed to reproduce the scenario I was seeing before though) To clarify, this appears to be looking at the entire condition or formula for the trigger.old record and the trigger.new record. If conditions(trigger.old) == false && conditions(trigger.new) == true, execute the actions. Can't really find any documentation to support this, but seems to make sense. May 5 '20 at 20:43
0

I'm seeing some interesting / unwanted behavior when evaluating a cross object field with 'only when specified' checked. In my case the update of the field on parent object kicks off a process on parent object. The process updates a field on child object, which kicks off a process on child object. The node in child object evaluates the field on parent object (only if specified changes are made) but does not fire. The other nodes in the process, which dont evaluate fields on parent object, but also have it checked, do fire. Full gory details below

Worked ok:

process on object A fires when field is set on object A
--> this process updates a field on child object B
--> this kicks off a process on object B which evaluates field on object b and only executes when specified changes are made to the record

this works if object b is created before field is set on object a but does not work if object b is created after the field is set on object a

so...I added a node to the process on object B which sets the field on object b if the field is set on object a.

discovered that this does not work unless recursion is enabled as the downstream node will not 'see' the update to the field on object b in the same process. i wanted to avoid that, because i fear process builder and have exponentially more fear for a recursive process.

so i changed the evaluation criteria for the process on object B to evaluate the field on object A instead of the field on object B.

process on object A fires when field on object A is updated
--> process updates field on child object B
--> this kicks off process on object B which evaluates field on object A and only executes when specified changs are made to the record 

This works fine if object B is created after field is updated on object A (because its already checked on object A, so node fires on record creation). But if object B already exists, the node in process on object B does not fire when object A is updated, as'when specified changes are made' does not appear to see the field on object A as being changed.

possible new approach i am thinking could work.

process on object A fires
--> process updates field on child object B
--> this kicks off a process on object B that evaluates field on object A OR object B and only executes when specified changes are made to the record 

this may just work for both scenarios : object B created before object A. or maybe i should just enable recursion and go on with my day.

UPDATE evaluating a parent object field with 'only execute when specified changes are made...' appears to always be false, even when combined with fields on the master object

This fires:

[Account_Request__c].Email__c &&
[Account_Request__c].TRP_Signed__c

This does not fire

[Account_Request__c].Email__c &&
([Account_Request__c].TRP_Signed__c || NOT(ISBLANK([Account_Request__c].Employment_Record__c.Policy_Signature_Date__c )))

This does not fire

[Account_Request__c].Email__c &&
NOT(ISBLANK([Account_Request__c].Employment_Record__c.Policy_Signature_Date__c ))

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.