I’m working on a large and complex process where we do not use User Input Tasks. Instead, we implemented a pool-based approach, where each group has its own pool of requests.

Question

Hi everyone, 
 I&rsquo;m working on a large and complex process where we are not using User Input Tasks. Instead, we implemented a pool-based approach , where each group has its own pool of requests. 
 All request data is stored in the database . We also have an Admin Configuration interface that allows the admin to enable or disable certain tasks for specific groups. 
 For example, in the database we store a boolean flag:

true &rarr; the request/task should appear in the pool

false &rarr; the request/task should no longer appear

On the interface side, we are using a grid that queries the database and filters the tasks based on this flag to display the pool for each group. 
 The issue we are facing is the following: 
 When the admin disables a task (changing the flag from true to false ), the request still appears in the pool grid . It only disappears after performing a hard browser refresh . The standard refresh mechanisms in the interface do not update the grid immediately . 
 My questions are:

Is there a recommended way to force the grid/pool to refresh immediately when the admin disables the task?

Are there any best practices for implementing pool-based task management like this in Appian?

Is there a better architectural approach for handling this scenario?

Any suggestions or best practices would be greatly appreciated. 
 Thanks!

Stefan Helzle · Answer

1) There is no way to update a UI on another machine. But you could do a automatic refresh. 
 2) Yes. Use user input tasks. While I know that there are scenarios where they do not fit, in 16 years, I was able to use them for all apps I have ever built. And when it seemed like they would not fit, it was typically a business issue calling something a task which in reality it was not. 
 3) See 2.

Mike Schmitt · Answer

You can't update **instantaneously** on the parent grid interface, however it's pretty trivial to use a!refreshVariable() along with a refresh interval of 0.5 (30 seconds) to refresh the displayed tasks pretty often. 
 In the case that someone clicks on one of the "Tasks" in their list that has already been removed by an admin but was still showing up on their interface - at the beginning of the process, simply re-query by the "task ID" to double check its removal status, and if it is removed, route the user to a dummy interface informing them that the task is no longer available. 
 Not a PERFECTLY seamless solution, but it should easily satisfy >99% of use cases.

Harsha Sharma · Answer

Immediately after admin action grid refresh will not be possible. At earliest refreshAtInterval parameter of the grid data can help refresh the grid. So expect delay there along when regular data refresh design and performance impacts! 
 I would suggest an alternate design - IF you are ok to not refresh the grid after admin actions and still have the task link available - then just have a flag within the interface to check where task is still active or is turned off by the admin. If it&rsquo;s active show the task UI else show a message informing user that admin action has removed the task along with a submit button. This is simple effective solution without any performance impact or added complexity!