Sometimes, workflows may be launched only to be aborted by the launcher. Historically, this would result in lingering work items and/or workflowcases that might never be closed. IdentityIQ 6.1 introduces the concept of "transient workflows" -- workflows that create no persisted artifacts until the workflow has to pause (e.g. the workflow is backgrounded or a workflow form has to be presented to someone other than the workflow launcher).
The transient workflow concept was initial created to support the self-service registration option, preventing a proliferation of abandoned work items in the event that users attempted to self-register to IdentityIQ and aborted the registration process before they submitted the form for approval. It has proven useful in any circumstance where an initiating user could abort a workflow process with the desired resulting action being for IdentityIQ to behave as if the workflow were never launched.
Consider the example of a quickLink that launches a workflow to present a form to the user. If a user clicks that quicklink and then discovers they don't want to complete the form, they would click "cancel" on the form. A traditional workflow would save the form as a work item in the user's inbox and leave the workflowcase in a pending state, awaiting action by the user that they might never take. Marking the workflow as transient means that when the user clicks "cancel", the workflowcase disappears and no work item is created for the launcher at all.
To make a workflow transient, declare a process variable for it called "transient" and set it to true.
That is very useful and have avoided many unclosed workitems. I have one question though. You mentioned that the workflow will not persist until it is "paused". Beside the scenario that you mentioned about opening a workflow form to a different person, is there any other way to persist or "pause" the workflow?
The use case I'm looking for is to start a workflow in transient mode. Then, user may continue through multiple workflow forms to enter the data. At some point of time, user may select to "save" the state he/she is in and persist the workflow.
One idea is to intercept the "back" button functionality to create a "suspend" option that would route to a step that would background the workflow. Of course, that means you couldn't use the action=back option to drive other actions, but if you don't need it for other operations, that works.
What I'm stuck with is how to background the workflow in the workflow step after the user click on the back button. Beside opening an approval form to someone else, is there a function or variable that I can set to make the workflow goes to a background?
Specify a "wait" step and that automatically backgrounds the workflow. Your form step (that you are suspending) should return its values to workflow variables and then after the wait step, you would probably need to create another form step that would re-create the previous form. After the backgrounded step, the subsequent form step will create a workitem in the user's inbox. The workflow after that form should route back into the normal flow.
This could get really complicated if you are allowing them to suspend at several different points in the workflow, so use with caution.
Is there a way to prevent a workflow subprocess, that's launched from a transient workflow, to not be transient without backgrounding the workflow? I have an initial form that a user fills out which is supposed to present them with another form once submitted. I do not want that initial form to persist, but I do want the latter one to persist and get archived. So I've made the parent workflow with the initial form transient and the subprocess with the latter form not transient but that doesn't work. It looks like the subprocess is still transient.
I already tried that and it doesn't work. I'm guessing it's because the subprocess is part of the same workflow case. However, if I launch the workflow using the API then it works, but the problem with that is that the workflow gets launched in the background so the form that it should present to the launching user gets sent to the user's inbox.
Before I learned about the transient workflows, I had implemented something similar by using the button types. Instead of a cancel button, you can use a back button (reject) and in the next transition use that to directly go to the Stop step. That way you don't need to mark the workflow as transient. The button title can just be "Cancel". Also note that you can give buttons parameters, so you can create even more specific behavior if necessary.
