I’m new to the ServiceNow integration in SailPoint ISC, and we are looking at using the SDIM to automatically generate ServiceNow tickets for applications that SailPoint cannot connect to. I’ve been doing a lot of reading and poking around with this, and I’m unable to get a clear answer on what you are supposed to use for the “source” for this. In my mind, a disconnected application is just that, disconnected, so setting up a flat file connector or delimited file connector doesn’t make a lot of sense unless it’s just a placeholder. I have seen examples of it being used to load fake entitlements for provisioning, so that makes some sense. The issue is that we were told the connector will also need to aggregate accounts into ISC from this “disconnected” source, which doesn’t make sense at all? What if you are wanting to trigger the creation of a ticket for a piece of hardware(laptop), there would be no account to read for this from anywhere.
So, in simple terms, can someone explain what you use for the source connector (source type), what you use it for (I do understand that it’s specified in the SNow integration config), and does it need to actually aggregate data on a regular basis, or is it just a placeholder after initial setup?
The entire landscape of SailPoint’s new Quick Compliance Connectors is that they are read-only, but they don’t require as much time or friction to set up.
There are also even more “disconnected” sources that you can’t even get a read-only connection into and it requires you to manually load a flat file into SailPoint with the “latest” export from that system.
Both of these are good candidates for using the Service Desk connector
I had this happen at a previous job where people had access in Fidelity to manage certain things about our stock plan. We had no way of connecting to it via SailPoint and had to basically request a user export from them periodically before we did our SOX access reviews. If there were any revocations from the certifications, it created a ServiceNow ticket for someone to manually handle.
Using that, you now have a means of operating your access review process in a somewhat centralized manner, which is a big step above the “emailing around spreadsheets” method that A LOT of orgs do today.
There are plenty of circumstances where apps that are capable of handling provisioning from SailPoint aren’t set up to do so because orgs just “aren’t ready for that reality”, so the Service Desk Integration makes a lot of sense to “get started” in integrating your app in SailPoint
Back to your question about why sources are required - This is basically telling SailPoint “Hey, I can’t do provisioning in these sources, I need you to go create tickets when you have provisioning requests for them”
Wow, thank you for the thorough response, much appreciated! I think I’m understanding the reasons why SailPoint requires a source, even though it makes it difficult to “have to” connect to an application, provisioning still needs a source to work off of. That being said, the concerns that were brought to us were that if SailPoint didn’t aggregate “evidence” that the provisioning happened, meaning pull back in the account with access, it would keep trying to provision the access every time a refresh occurred. (and create a new ticket) Does that tend to happen, or will the identity reflect the access/entitlements that were granted without relying on an account to also be listed to validate provisioning?
Along that same question, have you built a ServiceNow integration to an app that never aggregated the account data back in? I think in a few situations we could pass back a delimited file like you mentioned, but some of the apps could be air-gapped in a secure network, and I hate sneaker-net.
It uses the ticket status to determine if provisioning was completed.
I can’t remember exactly what it does to the account that exists in sailpoint. I believe it shows the account as having the entitlement assigned which would only change if you do an aggregation (by loading a file or through a directly connected source) and that data says it doesn’t have it.
If the entitlement is assigned via access request, it won’t create another ticket if it sees later on the account doesn’t have the entitlement assigned.
If it’s assigned via a role with assignment criteria (meaning it’s assigned automatically and therefore “sticky”), it’ll more than likely retry to assign it (by creating a ticket) if the entitlement isn’t shown as assigned after an aggregation
Ah okay, that was the concern they were voicing, they want to build this into a role with assignment criteria, so that may cause issues if it’s not aggregating the account back into SailPoint. I guess in the case of a completely disconnected application, we may have to look into some workflow automation in ServiceNow that would write a placeholder record into a SNow table when the ticket is completed for SailPoint to aggregate back in. It would be nice if SailPoint had some way of storing the SNow ticket record as the account evidence of provisioning, that would make it much more universal for accounts, entitlements, physical access, hardware, etc.
The “source” for a disconnected application is just a placeholder
Use a Delimiter File Source 99% of the time
You do not need accounts unless you have a business reason
The source exists so SailPoint can trigger provisioning → SDIM → ServiceNow ticket
Aggregation is only needed to load entitlements, not real users
Hardware like laptops does not require accounts.
Based on what you and Mark have said, I think we will give this a try for a limited population to see how it goes, as it sounds like it may still work for our application. We can always pivot if it looks like it’s doing something unexpected.
Hello Frank, as someone stated above. The “source” for a disconnected application is just a placeholder. Now when it comes ISC → ServiceDesk , I’m not familiar if there is an existing OOTB connector; however, there are OOTB Portal interfaces on SNow Market, if you’re looking to integrate ISC or IIQ as platform.
Not so long ago I worked in an integration with IIQ keeping the requester and fulfiler end on ServiceNow, while business logic in relation to IGA in IIQ. Similar concept goes to ISC.
If you have any further questions please feel free to reach out.
