Advanced Workflow (AWF) Design Best Practices from Archer Scripts #2 Avoid Looping Transaction Issue

Advanced Workflow (AWF) Design Best Practices from Archer Scripts

– #2 Avoid Looping Transaction Issue –

In the last article (#1 Routing Node) we mentioned that the “famous” Looping Transaction Issue deserves its own topic.  At the end of the article, we showed a typical looping issue that would cause unexpected issues. In this article, we’ll take a closer look at this issue and discuss how to work around it.

What’s a looping transition?

A looping transition is when you transition (draw a line) to a node that’s already been visited. It’s represented by a dotted line in Archer. Usually, Archer automatically sets it for you when it detects it’s a looping transition. But it’s not always correct.  

Common Issues

Using the same example from article 1 below. If the flow goes through the green route, the looping transition (dotted line) from Reviewer 1 back to Submitter would be valid. The flow did go through Submitter before it went to Reviewer 1. 

No alt text provided for this image

However, if for whatever reason the record needs to be re-enrolled, and it was sitting on the Reviewer 1 node at the time, upon re-enrollment our lovely router would send it right back to Reviewer 1 as shown in the route below.

No alt text provided for this image

In this case, the looping transition would not be a valid looping because the flow has never been to the Submitter node prior to the Reviewer 1 node.  In this case, the workflow will crash. 

Workaround

To work around this issue, in this particular scenario, we need to send the record back to the Router node and let the router know where it needs to go by using an Update Content node.  See below, when returned, it goes to an Update Content node to set the “Node” helper field to “Submitter” so the router knows where it should go next, then it goes to the router. Now the transition is a valid looping because it has been through the Router node.  Next, the router will evaluate it and send it back to Submitter.

No alt text provided for this image

So the key here is to always examine the node where a looping transition points to carefully, to see if there might be a scenario the flow might skip this node, if so, that would make the loop an invalid loop.

Organizing Flow Chart

If there are a lot of loopings, you might find it’s difficult to see the actual flow from all these lines going everywhere. In this case, from the flow chart itself, you can’t really tell where the return is actually going to the Submitter from an end user’s perspective. So what I like to do is to manipulate where you put the lines to organize them in a way that actually represents the flow. See below I point the line back to the Submitter to depict the business flow. 

No alt text provided for this image

So it looks like this.

No alt text provided for this image

Getting a little more organized.

No alt text provided for this image

The ultimate solution

So now you have a good idea about this issue, what would be the ultimate solution? You might think the example above is too simple and too obvious with that overarching router there to serve. Yes, in the real world, when you have hundreds of nodes, dozens of branches, you might run into scenarios where it seems very difficult to figure out. What we found is that you can always use this trick to resolve almost all scenarios (at least we haven’t found anything unsolvable using this approach).  This can be demonstrated fairly easily. All you need is to recognize this pattern and apply it to your scenario. 

Below is one quick example, using this simple model, you can apply this to your scenario. Let’s say you have hundreds of nodes in this black box, then there is this little branch that sticks out where you need to loop back and forth and you found there is a looping issue. 

No alt text provided for this image

As you can see, if it goes from User 0 to User A, then from User A to User B, then User B back to User A, it’s not an issue. But if it goes from User 0 to User B, then from User B to User A, the loop will break.

To resolve this, follow these steps.

  • Single out the two nodes where the looping occurs. 
  • Insert an evaluate content node.
  • Add an update content node.

Applying this to the example above.

Single out the two nodes where the looping occurs

This is to break them from the original source node, in this case, User 0.

No alt text provided for this image

Insert an evaluate content node

This is to use an evaluate content node to reconnect the pair with the source node. Create a helper values list field to indicate if it’s going to A or B. e.g., Set Helper to “Go to A”, the Evaluate Node will send it to User A.

No alt text provided for this image

Add an update content node

This is where the loop happens. The goal is to go from User B to User A without a looping break.  Create an update content node (circled below). Set the node (where the looping originally goes out, in this case User B) to point to this update content node. Update the helper field to a value that represents the targeting node, in this case, set the helper to “Go to A”.  Now the evaluate content node will send it to the targeting node User A. This concludes the looping without breaking it.

You can see that here the evaluation content node serves similarly as the router node in the previous example. But it is created specifically to resolve this looping issue. 

No alt text provided for this image

This concludes the looping issue. Please let us know your thoughts. Feel free to send us a scenario if you can’t find the solution to fix the looping issue. 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top