We have a unique user request that the user wants to submit change request to an approver group without having to close the interface and click another start process link in the read only grid. Currently the process model has a Process Start form that the user can edit changes. Here is the issue they want to send the changes to an approver group while keeping the interface page open to use a dropdown to select another entity and submit a request multiple times. Basically he users want to be able to submit change request and not have to keep going back in to the interface page from a link each time.
Discussion posts and replies are publicly visible
This user does not even need a start form - build them a specialized Site Tab with an interface containing the grid and utilizing links calling (as Stefan mentioned) a!startProcess(), in such a way that instances can be launched silently without the user needing to leave their current form.
I agree so far that is the same the only issue is staring a User Task without closing the form. They don't want the person who made the request to make changes to have access to the User Task to approve the changes. Appian only has User Tasks as a Process Model Smart service, so i can't call it in the Interface page.
So... I think you're confusing a few different things together here.
On a Site page, you would have User A view a grid / some sort of list of items that need parsing / launching (whatever you need, really). The user can view individual items and even enter cursory introductory data, then click something that connects to a!startProcess(), passing in the item in question (as well as any initial data that may have been entered by User A) - that starts a brand new process, asynchronously and in the background, where you would launch a task and assign it to whoever you want (usually a group containing various different folks who can pick it up from their queues).
There is absolutely no implication here of the original user "having access to the approval task" as you say - so this design pattern should fit your use case perfectly unless I'm majorly missing something here.
Mike,
Doing that causes the tempo site to pop-up since there is no start form interface tied to the 2nd process model.
John Camacho said:Doing that causes the tempo site to pop-up since there is no start form interface tied to the 2nd process model.
I'm not sure what you mean. Nothing should "pop up" at all - the new process will launch asynchronously in the background when the first user deals with individual items. There would not be any "start form" on that process - there would just be a task that gets assigned to the subsequent user or task-picking group.
Can you share a snippet of what you're trying at the moment, within the initial user's interface? I have no idea how you're getting "tempo site pop-up" from this.
Thanks for the input after looking through the code that was built i noticed the it is a nested interface and that was causing the problem with the a!processmodel call. After i pulled out the call to the parent interface it works fine.
Great, thanks for confirming.