Segregation of Duties (SOD) in ServiceNow Catalog (integration with SailPoint IIQ)

[begjo (Joveria Beg)]

I have completed the integration of Sailpoint IIQ with ServiceNow Catalog.

Policy Scheme set up in LCM Provisioning is “Continue” and that works as expected in the NATIVE SailPoint IIQ’s role request however it won’t allow request to be submitted unless one of the conflicting roles is removed completing before submitting the request if done via ServiceNow Catalog Portal.

Why? Any documentation on SOD for ServiceNow Catalog?

[patrickboston]

That SOD validation that is occurring in the ServiceNow integration is completely separate from what you have configured in your IIQ workflow. SailPoint developed custom REST endpoints that perform the SOD validation, ensure the user doesn’t have that access already, etc. For your options in the LCM Provisioning workflow to be respected would mean the workflow case actually needs to be kicked off in IIQ and at the point of hitting the submit button in ServiceNow, there is no workflow case in IIQ yet, just the REST validation endpoints are being hit.

[begjo (Joveria Beg)]

Thanks Patrick, there is “LCM Provisioning” being called even in ServiceNow as seen in the screenshot below. Is this not being utilized during the SOD?

[patrickboston]

LCM Provisioning isn’t invoked until after the SOD validation is complete via the REST call to IIQ. Once validation is passed, then LCM Provisioning is invoked in IIQ to handle the provisioning.