2

I've just run into an interesting Process Builder issue in a client Professional org. I have reproduced it in a small scale on my dev org. Here is a nonsensical minimal example:

  • I added two text fields to Account called ChangeThis and CopiedHere.
  • I added a formula field to Account called EchoesHere that simply equals the value of ChangeThis.
  • I created a Process that is set not to allow recursion and triggers on edit of Account. The first and only condition is that ChangeThis has changed.
  • The first action is to update ChangeThis to concatenate "!!!" to the end of the same field.
  • The second action (within the same condition) is to update CopiedHere to equal EchoesHere.

So now, if I edit ChangeThis to equal "Hello" in the UI and save, I get:

  • ChangeThis: Hello!!!
  • EchoesHere: Hello!!!
  • CopiedHere: Hello

So evidently Process Builder is only retrieving the formula field value at the beginning of the process, rather than calculating it "live" after any updates. Is there any way to force Builder to refresh the formula field mid-process?

Is this "working as intended"?

1

It is working as intended.

Since in the process builder, you are updating CopiedHere to equal EchoesHere. and EchoesHere is the formula field, so its value will be reflected after committing of data.

So, during middle of execution EchoesHere = Hello, so as CopiedHere also and after committing,

EchoesHere = Hello!!! (which is same as ChangeThis)

and naturally CopiedHere = Hello (because of formula field condition)

Refer Triggers and Order of Execution

Hope it makes sense!

  • Yes I'm familiar with order of execution but formula fields are not actually data stored in the DB so their behaviour is undefined in the order of execution. My colleague made the reasonable assumption that after updating a field in Process Builder, requesting the value of a formula field would calculate that value live based on the updated value. This left us stumped for weeks. – Charles T Nov 10 '16 at 14:39
0

Yes. Just like the workflow field update operation, all field operations behave as if they were performed simultaneously. Multiple updates to the same field in the same workflow update will have undefined behavior. To get the desired output, you'd have to use recursion.

If you read the logs, you'll see that the engine actually evaluates all rules, then calculates all updates, and finally apply all changes, followed by any recursion, if specified.

  • It seems that Process Builder generates very obfuscated logs. I've been trying to follow them but I can't make heads or tails of it. Do you have a suggestion for a guide to interpreting those logs? In Process Builder it does seem to be the case that updating a field on the current record and then reading its value will show you the updated value. And we're always told that formula fields are "live" values calculated on the fly. So it just comes as a surprise that those fields are not as "live" as expected in Process Builder. – Charles T Nov 10 '16 at 14:42
  • @CharlesT Formulas are "live" from the moment they're loaded from the database. The key here is loaded from the database. They're not recalculated in memory every time a field changes during a transaction, only at certain key phases in a transaction. That naturally has some confusing side effects, particularly with PB/workflows, but that's how the system works today. As for debugging PB, let me see if I can't come up with some more details for you. – sfdcfox Nov 10 '16 at 15:15
  • Thanks for the info. I know that Apex has a "recalculate formula" function for formula fields... it would be nice if PB could have that too. – Charles T Nov 10 '16 at 15:56
  • @CharlesT That's actually the purpose of allowing recursion, because the values would be updated after a field update. – sfdcfox Nov 10 '16 at 15:58
  • Unfortunately we're in a situation where a Professional Edition client has a maximum of 5 active Process Builders so we end up with a very long chain of conditions and actions in any one Process. Inevitably, allowing recursion causes an infinite loop and it fails. – Charles T Nov 10 '16 at 16:15

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.