cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Transient workflows

Transient workflows

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.

     <Workflow name="Vanishing Workflow" ...>

          <Variable name="transient" initializer="true"/>

Labels (1)
Comments

Thanks for the reply Jennifer. In my case, I'm submitting a request and the request has an attached form, the form is presented to the user after the request is being processed. I can see the request ID being generated and is in executing status. If I cancel the form, the request is stuck in Executing status and the work item is routed to the user.

Your best option in this case may be to remove the cancel button and add a "back" button, with "Cancel" as the label. Immediately after your form, you check the approval status and if not approved, go directly to the end step. Otherwise continue.

So, you add a condition to the current transition from the form to the next step, and add an unconditional transition to the end step:

<Transition to="My next step" when="approved"/>

<Transition to="end"/>

but when I cancel, I do not want an approval workflow to trigger.

That is exactly what you achieve with the solution above: skip all next steps and go to end if not approved. Approval status is for all forms, not just for an actual approval.

- Menno

this function is very usefull. But you get an error with version 7.2p2, when you start an 'Approval' Step:

     sailpoint.api.Workflower:7802 - Error while unlocking workflowCasenull

     java.lang.IllegalArgumentException: id to load is required for loading

the workflow does not stop but the error message is very confusing, especially when you track the log for errors.

It's likely a combination of factors that causes this. Perhaps a variable that is not persisted when the workflow is backgrounded?

Hi Menno,

please check it with this small example:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Workflow PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Workflow explicitTransitions="true" name="Transient-Check" type="Subprocess">

   <Variable input="true" name="transient" initializer="string:true">

   </Variable>

   <Variable input="true" name="selectedBundle" initializer="string:true">

   </Variable>

   <Step icon="Start" name="Start" posX="100" posY="0">

   <Transition to="Go to Approval"/>

   </Step>

   <Step icon="Default" name="Go to Approval" posX="200" posY="0">

   <Approval name="Test A" return="selectedBundle" send="" owner="ref:launcher">

   <Form name="Bundle select">

   <Attributes>

   <Map>

   <entry key="pageTitle" value="Hello Test" />

   </Map>

   </Attributes>

   <Button action="next" label="Go" />

   <Button action="cancel" label="Cancel" />

   <Section>

   <Field displayName="Testfield" multi="false" name="selectedBundle"
   type="Bundle" required="true" >

   </Field>

   </Section>

   </Form>

   </Approval>

   <Transition to="Show selected bundle"/>

   </Step>

   <Step  icon="Default" name="Show selected bundle" posX="300" posY="0" >

   <Script>

   <Source><![CDATA[

  import sailpoint.object.*;

  Bundle bundle = context.getObject(Bundle.class, selectedBundle);

  if (bundle != null) {

  System.out.println("bundle "+bundle.getName());

  context.decache(bundle);

  }

  ]]></Source>

   </Script>

   <Transition to="Stop" />

   </Step>

   <Step icon="Stop" name="Stop" posX="400" posY="0"/>

</Workflow>

I've tried this workflow in both my 7.1 and 7.2p2 environments and it works just fine.

Hi Menno, Now I have tested it with my Sandbox IIQ 7.2p0 -> no problem. But after upgrading to 7.2p2 -> I got this error too.

That is strange, as on my 7.2p2 installation, no problem... Perhaps, you should open a support call.

Version history
Revision #:
2 of 2
Last update:
‎Jul 10, 2023 05:18 PM
Updated by: