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.
It is marked as fixed in 7.2p3 and in 7.3 (and 7.1p5 - apparently affected at least one 7.1 patch version as well). I don't know the dates for those releases, but the good news is that it also doesn't appear to affect any functions of the workflow - just an unexpected error message in the logs.
If you are a customer, please contact your CSM to ask about this. If you are a partner, please contact your Partner Manager. They should be able to get you that information.
So I am getting this error in a workflow on 7.2p2. If we receive errors on an file import process, we display a form with a count of errors and what the errors were. This is currently bombing out and going straight to main login page and I get the error everyone else is getting. We are losing the last error page that displays the error count and reason.
