0

With the exception of using Timed actions in Process Builder (where it takes at least a minute if you set it for "an hour ago"), is there a way to have two Flows that cause Object A to touch Object B (and vice versa) without ending up in a cyclic relationship (or and endless loop depending on your view)?

  • Process Builder 1 fires when Account is touched; this touches custom Customer object

  • Process Builder 2 fires when custom Customer object is touched; this touches Account object

Unfortunately we have fields that need to sync between these two, and when you touch certain things (in our case, Account Name), it causes an Apex error.

The goal is to stay out of Apex "directly", stay within the GUI for maintaining this, but also to not have Timed events that take a minute (to hours) to fire.

Error:Update failed. First exception on row 0 with id a5A210000009VLmEAM; first error: CANNOT_EXECUTE_FLOW_TRIGGER, The record couldn’t be saved because it failed to trigger a flow. A flow trigger failed to execute the flow with version ID 30121000000186x. Flow error messages: An unhandled fault has occurred in this flow
An unhandled fault has occurred while processing the flow. Please contact your system administrator for more information. Contact your administrator for help.: [].........Stack{Class.rstk.ObjectSaver.updateObject: line 63, column 1 Class.rstk.THAccount.updateRSCustomer: line 1449, column 1 Class.rstk.THAccount.doBeforeUpdate: line 759, column 1 Class.rstk.TriggerHandler.beforeUpdate: line 243, column 1 Class.rstk.TriggerHandler.delegate: line 102, column 1 Trigger.rstk.Account: line 3, column 1}

Improve this question

1 Answer 1

Reset to default
1

Put an isDirty checkbox on the objects. THen on either object, your immediate actions would do the following: If we have two objects with two processes A and B

Immediate Actions A

  1. if(A.isDirty is false) make A.isDirty true.
  2. if(B.isDirty= false) update object A
  3. always make isDirty false

Immediate Actions B would be the inverse of this.

then updating A will: fire A1--> fire A2 --> fire B1-->not fire B2-->fire B3-->fire A3-->STOP

Improve this answer
6
  • Are you sure? I thought the Order Of Execution would still apply and BOTH immediate actions would happen at once..? I recall dealing with this in another way about 5 years ago and having to have some Apex written. I'd love to believe you are right. When I get time, I will certainly try, because a "toggle field" for this purpose "makes sense", but I long SINCE (back then) took this OUT of my head as a possibility (then, using Workflows).
    – AMM
    Mar 15, 2017 at 19:32
  • Actually, your way of describing this is different than I recall trying long ago. This sounds more robust. Again, will try ASAP. Thanks.
    – AMM
    Mar 15, 2017 at 19:33
  • Feel like there is room for problems, UNLESS the dual field updates to A.IsDirty happen all within the same OOE - if so, they act as TEMPORARY VARIABLES, and I believe that works. By the time the actual Commit-of-DML happens, IsDirty never actually changes IN THE FINALLY STORED DATA. Do you agree? Still writing this, but my past experience is making me question it continuously, because I really feel like I'm travelling down the same road now. Grr. If IsDirty ever commits in step 1, ANOTHER user and/or flow touching the record could confound things. (don't think it will)
    – AMM
    Mar 16, 2017 at 12:52
  • Did not work; however, I believe the reason is not the flows, but Rootstock Apex. My A-flow does ONLY EDITS to the A record at this time. It NEVER touches the B record at this time. B-record is being touched by Rootstock Apex code... and somehow it appears it's in a different DML/operation, because the B-record flow is firing as if the A.IsDirty marker is not set to TRUE. :-( I have a detailed message in to Rootstock about it. Apparently THEY need to have a bypass I can access to BLOCK their A-record Apex from firing selectively. (sigh)
    – AMM
    Mar 16, 2017 at 14:01
  • I agree with what you said above. Can you disable the triggers and retest? Concurrency shouldn't be an issue because everything above happens in a single transaction.
    – Matthew McKinley
    Mar 16, 2017 at 15:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .