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.
- 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.
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.