We’ve configured the IIQDisabled flag in the account query of a JDBC source to reflect account enable/disable status in IdentityNow, based on the status column in the account table. This works correctly when the column value is updated appropriately.
We now have a requirement to:
Enable/disable the account on the JDBC source based on specific lifecycle states.
Generate tickets for these actions.
How can we ensure the account is disabled in IdentityNow during one lifecycle state, allowing it to be enabled during a different lifecycle state, while ensuring tickets are created for both actions?
Has anyone encountered a similar requirement? If so, how did you implement this — or do you have any ideas or best practices for achieving this?
For Enable/disable on specific lifecycle state, you can use JDBC provisioning connector rule and add source to Identity profile. You can auto set account enable or disable on different lifecycle state based on your requirement.
To generate tickets, you can utilize workflow and trigger the workflow on identity attribute change. Whenever lifecycle attribute changes of an identity, workflow will be triggered. You can fetch that identity and check if that identity has that source or not, if present, you can open ServiceNow ticket accordingly via workflow.
Hope you get an idea on your requirements. Thanks.
Thanks for your response! We also have a requirement to create tickets for other changes to the account i.e. create or update access. We have more than one sources with such requirements and because of that we added all our sources into the Service Desk integration. The integration is able to create a ticket for Create, Modify access or even for disable request. Like you mentioned, we have added our sources to disable list on particular life cycle state and that triggers a ticket but the problem is the account stays enabled and therefore on the next identity life cycle state where it needs to enabled it doesn’t create a ticket to reactivate the account. Hope this explains the problem
Also, as per this discussion, it seems that once we add a source to service desk integration any rules defined on the source won’t trigger - Before Provisioning Rules and SDIM Integration. Otherwise, we could have used the rule on JDBC source to flip the appropriate flag on the enable/disable actions. Also, it seems it is not possible to skip ticket creation for certain actions once you add the source SD integration. So, I guess our option is to let SD integration create tickets for CREATE, UPDATE and DISABLE action but do the enable ticket via Workflow on LC state change?