Update data and close task based on input from a different part of the process?
The business is wanting a process/forms built in a way in which I need some guidance. I know how to do one or the other, but not how/if they can be meshed together.
1) They want action item tasks assigned to task owners. The task owners have a simple form to complete. The tasks show in their task dashboard, and they get reminder emails.
2) They want others to be able to update the task data through an all inclusive form.
Here's the scenario:
The all inclusive form will have multiple sections where any person can update the data in any aspect, including data for the action item tasks. One of those sections is a screen where I will have tasks that they can assign. When a new task is created and assigned and submitted, the workflow goes to the standard task, assigning the applicable person (then that assignee gets an email, and they can complete the task at some point. The task shows in their dashboard, and they will get reminder emails. That's all good.
However, a user can go back to the all inclusive form and update data pertaining to a given task. So like if a supervisor wants, they can go to the all inclusive form and change the tasks for his people to a status of complete or add notes, change the due date etc. For example, to clean up where his people have forgotten to close a task, or even to update information about the task.
A) if he changes information on the task, how will that update to the actual task form so the new info shows when the task assignee goes in to the task form? I push data (all through the process) to a SQL database. Is there a way to refresh the data to AgilePoint (from the SQL database) so that when the user opens the task, it's refreshed data?
B) If the supervisor changes the task status to complete (just a field on the form) and wants the task itself terminated, how can I do this? Otherwise, the actual task activity is still there and the user will continue to get reminder emails, it will show in his task list, etc.
Is there a better way to do this? For instance, could I just have the all inclusive form (no assigned task forms in workflow), but be able to trigger emails to the "assignees"... so mimic a true task. I know it wouldn't show in their dashboard, but if I can get emails triggered, that would be the big accomplishment.
Thanks for any help!
Gwen
-
Gwen - I am curious: How does the "all inclusive form" work? If someone opens that form and edits data or marks one of the individual tasks complete, do they then submit the "all inclusive form"? And if so, does the process then loop back around so that the "all inclusive form" is generated again for making further changes?
-
Hi Loren, that's correct. The "all inclusive form" is a start task (they either enter the form ID or do a filter search to select one, then I run a sql query to pull everything from the database). They can make changes, then submit. I haven't finished the process yet, but then I set some field values, convert dates etc, and write back to sql and the process ends. Then someone else can do it. I know there is a risk that 2 people could open the same form id at the same time. Then I guess the last to click submit wins (would overwrite any previous submits). I don't see anyway around that (thoughts?), but in this scenario, I don't think it would happen (but I'll make the users aware).
What I have to learn is since I can't do the action item tasks in the "normal" task way. I need to build another process that "listens" for a trigger that gets sent to sql and then kick off emails to the task assignee. I've only ever made processes that started with start tasks... so I get a new learning experience LOL.
-
It sounds like what you might need to do is kick off a sub-process for each new task that is created by the "all inclusive form". That way each of those tasks will have its own unique Process Instance ID. You would then need to save that Process ID in the SQL table that contains all the other data about that task. When you kick off the sub-processes, you can set the main (parent) process to not wait for completion of the sub-processes. That way you don't have to keep that parent process active and the child sub-processes can live on as long as needed.
Then if the supervisor initiates the parent process again and updates data on one of the existing sub-tasks, you would update the SQL data for that sub-task using the Process Instance ID as a key field for that sub-process. Then on the sub-task form itself, you would need an Auto Lookup that executes on Form Load so that it pulls in the most current data. The only danger there would be if a user had that sub-task open while the supervisor is updating something for that task.
For your second requirement where the supervisor can mark the task complete: You should be able to use a REST API call to cancel the child process. So if the supervisor wants to cancel one of the tasks, you would get the Process Instance ID for that child task and execute the REST API call to cancel that process. Documentation on the "Cancel Process Instance" API call can be seen here:
https://documentation.agilepoint.com/11/developer/restmethodCancelProcInst.html
Hope this makes sense and helps.
-
Loren, I hope the offer to show me how to set up an AgilePoint REST API call is still good :). I'm at that point (sorry it's been so long, I got pulled onto another project for about a month). I actually need to do a "cancel", "reassign" and "update" call to handle 3 different situations. I'm at a total loss. My email is gwen.wilson@everpack.com Send me an email when you get time. Thanks!
Please sign in to leave a comment.
Comments
8 comments