There are business processes out there which can take a very long time to complete. Think of claims management in an insurance company. When there is an ongoing law suite, this can take months or even years. But still, there are tasks in this process which need to be assigned, tracked and completed.
Translating this into a process driven application in Appian leads us to an important design decision:
“How do we deal with tasks that take a long time to complete?”
The Challenge
The most simple approach is, to just assign that task.

The first issue is, that you now have an active task in the users task list, which he cannot complete. This is a bad user experience. The user should only see the tasks he can actually work on.
But, there are two more technical issues with this implementation.
Second, this process takes up system memory for no purpose. Not a big problem for a small number of processes, but this will not scale.
Third, we cannot change the logic in that process for any already active instance. This becomes a problem over time when the business department develops new ideas..
The Solution
Some people say: “Why should I bother with Appian tasks! Let’s rebuild this in the database!”
While there are certain scenarios which might require such a radical approach, I advocate for staying with the Appian standard features as long as possible. They are easy to use and proven to work.
In this specific case, I suggest to go a hybrid way.
I, as a user of that application, love to be able to plan my work. What do I do now, what do I do tomorrow, and what needs to wait for some external event. When I open a task and decide that I cannot do anything with it for 3 months, I want to turn it into a follow-up which reminds me of itself in 90 days from now.
Do you know the self organization method Getting-Things-Done?
Great idea, let’s see how that works.

That’s the modification in the process model. The user interface requires some changes as well. Add an option to allow the user to decide about a follow up and the waiting period. Once the user opted for the follow-up, persists all required data to the database and create a follow-up item like this:
- id
- createdAt
- createdBy
- remindAt
- caseId
- processModelId
Next, create a process model which checks this database table for due items every day. This model will then dynamically start the process model identified by the processModelId and pass the data of the follow-up. Then change the main model once again.

You now have a model that reacts a bit differently on whether it is started initially or from a follow-up. That task can then have a normal tight deadline, but allows the user to turn it back into a follow-up as needed.
Display waiting follow-ups on the case record dashboard. And allow the user to trigger this follow-up manually in case that external event happens earlier than expected. This can be done using a record action tied to the follow-up record. Keep in mind to disable that follow-up in this case.
Summary
This is just a description of an implementation pattern. Please adjust the details to your specific requirements.
I implemented it successfully many times. It combines the power of Appian’s task management with the requirement for long running business processes in a perfect way and is easy to implement.
Simple and to the point š
Hi Stefan ,
This required user has to open the assigned task and then select follow up yes or no . The user has to open each and every task in the queue and then select follow up-yes or no as needed.
Is this correct?
Also how this can be achieved via database approach?
Hi Jordan, correct, the user will have to open that task and make a clear decision about how to proceed. The data required to make this work is persisted in the database.