Hi,
We are using a!startprocesslink() to initiate child workflow(a workflow related to parent workflow but can be executed independently) from the on-going parent workflow. Once the user completes the child workflow observing different behavior as per documentation of a!startprocesslink() "when the user submits the last form, the chain completes and the original interface is reloaded"
Please note: task 1 and task 2 are activity chained tasks or Parent Workflow and user can leave the task and resume any time. There is a task report where the list of tasks are shown to the end user referred as "Task List" below.
Ways to initiate child process -
1. user goes to record, initiate related action, completes Task1, then goes to task 2 , click on link to initiate child process
2. user goes to the task list, picks up ongoing task of parent workflow say task1, completes task 1 and go to task 2, initiate child workflow
3. user goes to task list, picks up task 2, initiate child workflow
in scenario #1 & #2 - when user completes/submits the child workflow, receiving pink error: "The Task Could Not Be Submitted The task has already been submitted."
In scenario #3 - When user submits child workflow, as per documentation original task is loaded successfully
Observation: seems when there is activity chaining, the URL is not refreshing and not holding the current/latest TaskId generated by Appian.
Any inputs. Is this a known behavior in 19.1?
Discussion posts and replies are publicly visible
I would strongly recommend against this design pattern. If you're starting from a User Input Task in an active process, I would exclusively use Submit buttons or links where the user is routed to the appropriate subprocess based on what button/link was clicked, and then routed back to the original task (a new instance thereof, technically) once the subprocess is done.
@Mike Thank you for the guidance.
what would be the best design if we want to keep the Parent Workflow "Task2" active and kick off the Child workflow simultaneously?
As suggested, if we use Submit button/link to kick-off the child process, the parent workflow's task will not be available in the task list, until the child workflow task is submitted by the end user.
Requirement is to allow user initiate the child workflow, the user may leave the child task and come back to "Task List" where they can resume the work on the parent workflow's "Task 2". To accomplish this requirement, as activity chaining is required, we are using a!startprocesslink() to initiate child workflow so that 2 independent tasks are active and available in the task list.
sivakumard0001 said:we want to keep the Parent Workflow "Task2" active
What's the use case for this? I have almost never seen a reason to do it this way, as it leads to confusion and potential bugs.
If you want the user to essentially stay on the original task and have a completely separate task kicked off by the link, the way I'd do this is by launching the subprocess asynchronously and assigning the new task to the user in the background, while the parent process loops seamlessly back to the original task. Once again this actually launches a new instance of the original task though it won't really seem that way to the user. All I'd suggest in this case is to add some advisory letting the user know that a new task will be landing in their task list.
IMHO the above two methods are the only worthwhile means of accomplishing something like this. I don't believe you'll find a workable "in between" solution where the user keeps the original instance of their original parent task while also chaining directly into a subprocess task - the functionalities are mutually exclusive.
Hi Mike, Thank you for the suggestion.
Would like to know if the observation is correct or not -
when there is activity chaining in process and user is moving from Task1 to Task2 to Task3, but URL always shows the taskId of the Task1 and does not display the current/latest TaskId generated in Appian?
Off the top of my head I'm not sure, though I don't think there's any particular guarantee that the current URL necessarily reflects the current task instance. What's your reason for worrying about this?
Not worried, but if the URL was refreshing using a!startprocesslink() for initiating a child-process from an Active task would not end up creating the above issue.
If the URL would be holding the correct TASKID in the URL, kicking off a process from an active Task using a!startprocesslink() would be possible. In this way, similar to dashboards/reports, if there is a requirement to update a related record from the task could be achieved, helping to build a feature and integrate at SAIL level in a consistent manner.
I believe the constraints I mentioned yesterday will hold true regardless of how the URL behaves. You should probably do some experimentation around this and get familiar with how it works, and come up with the process that will work best for you.
Sure Mike, Thank you for the suggestions.