Quicklinks are usually used for faster access of specific functionalities. Often a “no delays” workflow where the start and end of the workflow happen within one single launch of quicklink shall be launched by quicklinks. Usually these kind of workflows involve custom Sailpoint forms which would not be useful once the user stops using this quick link by navigating to some other page.
Conventional workflow launches are serialized by storing the workflow cases as XML objects. This leads to many work items and workflow cases which are incomplete and hang around the Identity IQ over long run. This might lead to performance issues and unwanted data accumulated inside IIQ.
This problem could easily be solved using the transient workflows. The main feature of transient workflows is that they don’t get serialized.
Without the workflow getting serialized, we have specific advantages.
- Workflow cases which are inactive specific to this workflow shall not be generated.
- Work items that are generated do not get serialized and as a result we don’t have any unwanted work items related to this workflow in user’s inbox.
This would result in cleaner environment where we don’t have unnecessary data.
Extra perk with logging:
Workflow variables in Sailpoint are serialized in non-transient workflows. This means that we can store only the objects that Sailpoint has capability to store as XML object. Log4J loggers are very useful objects which are disqualified as workflow variables because of this restriction.
As the transient workflows do not try to serialize the objects referred by the variables, Logger objects can also be stored in the workflow variables.
This provides us the flexibility to maintain a workflow level logger variable to use your custom logging. Rather than instantiating the custom loggers whenever we require them, we can simply use the workflow variable whenever required.
