We are redesigning a non-Appian applicaiton for a new build in Appian. In this tool, users are typically presented with the next work item immediately after completing one.
This seems akin to activity chaining tasks in Appian, a practice that we understand, and know it isn't a good fit. We have presented a proof-of-concept application that uses a sail interface without Appian tasks to mimic this push-mode, but we would either have to abandon or re-create functionality that comes standard with Appian tasks - Escalations, Exceptions, Group Assignment, performance metrics, Task Reports......
The concern among our stakeholders is centered around users colliding on task acceptance by following links from task reports.
E.g. two users click the same task link, and one accepts before the other. This would leave the second user reading a message that the task had been accepted by the first user and they would have to return to the task list and make a second attempt at finding/accepting a task.
Our stakeholders feel this is unacceptable, even in a low-volume environment.
Is there a best practice around task presentation and task acceptance that would avoid that possibility while still allowing us to leverage standard OOB Appian Tasks?
Discussion posts and replies are publicly visible
This sounds to me, in part, to be a data locking strategies issue.
I've just been having that discussion with a colleague as well. The problem our product owners perceive is that users may collide on picking up a task. My experience has been, that even in high volume environments, it's just not that big a deal, but I don't want to dismiss the concern either. One way of answering the question seems to be to abstract the view of available tasks through a database table that uses a lock approach to ensure users don't tread on each other's toes - so to speak.
We've done this in the past to achieve "Taskless" work assignment where everything was managed outside of process tasks, and the process models merely updated database tables which in turn were viewed/updated through a continuously looping SAIL interface.I think that model is unsustainable and really loses out on Appian's task management tools.
So I think we're going to try first to settle our user's concerns and try to stay as OOB as possible, but if we must answer collision avoidance we'll use a lockable-database-row-per-task approach.
Thanks for all of the input, this is a great discussion.