In process models, connectors have properties.

In this post, I am going to explain the option “Enable Activity Chaining” in more detail.

Chaining is Bad!

Yes, really! Let me briefly explain that, so we can discuss valid use cases in the next section.

It thwarts load balancing Appian process instances across the available execution engines. Appian tries to provide a fair share of resources to all active instances. Chaining raises the execution priority of the chained nodes to the max, impacting resource allocation to unchained nodes.

Priority only works when not everything is on the same level!

Chaining is Good!

Activity chaining comes from the old days of Appian where the UI capabilities were much more limited than today. UI elements were all static, and to implement a wizard interface, we had to implement each step as separate user input tasks. Then we enabled activity chaining to seamlessly navigate the user from one UI to the next.

Nowadays, I can easily implement complex UIs, and the need for using activity chaining for this use case is pretty limited.

But, modern times added two more valid use cases for activity chaining. I will now discuss these three cases in detail.

Consecutive UI

There are still a few use cases in which I need two or more consecutive user input tasks. Think of a file upload scenario, where you want to display the content directly after uploading the document.

In the first interface, the user uploads the file. But Appian finalises the upload only after a submit action, so I just add a second chained User Input Task in which I display the content. For the user, this makes no visual difference when you keep the two interfaces very similar.

Refresh User Interface

We now have a scenario where I display data to the user. That data is backed by a record. Some record actions allow the user to modify items, or add new ones. I want to make sure, that the UI refreshes only after all required nodes in the process are completed.

When starting a process in the background, using record actions or a!startProcess, Appian just fires off the process and immediately refreshes the UI. Typically, that refresh happens before that background process is completed.

I then enable activity chaining from the start node, up to the node doing the last required write records node.

I do not chain that last node because it is not necessary for showing the added or modified data to my user. And Appian can now execute that node with normal priority in the background.

Control Process Response

Update December 2024: With Appian version 24.4, a!startProcess() stops supporting activity chaining to define when control flow returns, and the onSuccess parameter evaluates. Head over to my post on the version 24.4 for more details. Now, consecutive UIs and screen refresh control on record actions are the only supported use cases for activity chaining.

This scenario is very similar to controlling UI refresh. But now, I use a!startProcess() in a UI or in a web API to start a process. Without chaining, Appian just fires off the process and a!startProcess() immediately evaluates the onSuccess parameter.

But typically that process queries or creates some data that you want to use. For me, a common scenario is, to create a PDF in the background and display that generated file to the user.

I enable chaining up to the node that generates the PDF and stores the id of the generated document to a process variable. a!startProcess now waits until that node is completed and I can fetch the document id from processInfo.pv.documentId.

Use the same technique for returning values from a process when building a webAPI.

Limitations

As like a real chain, chaining only works when there are no missing links. Then, the number of unattended nodes in a chain must be max. 50, including any nodes in sub processes, and the evaluation time of the flow less than 5 seconds.

If a chained flow ends in a User Input Task, an attended node, and the chain breaks, the user will find that task waiting for him in a task list.

Summary

Dealing with activity chaining is simple. Just don’t … except you want to implement one of the use cases I described!

• UI Wizards with specific requirements
• Controlling UI Refresh
• Controlling background process return

In case I forgot a valid use case, please let me know and I will add it.

Keep rock’in Appian and unchain our digital transformation!