I need to set the requested_for and requested_by/opened_by in the ServiceNow ticket, and pulling this data from IdentityNow…
As far as I know, we have to pass the sysID for the requester/opened by and for the requested for too.
Would you please guide me on this?
Also, we need to set the assignment group as well in ServiceNow, I’m passing this now as a static value is there is a way to do that based on the governance group for the source (if that feasible)?
Also, I need to know what is the content for the $plan attributes so I can manipulate or pick the values to be sent to ServiceNow…
The last thing, I need to troubleshoot and track the requests, So is it should be dumped in the log files or should I enable something…
Any thoughts?
Thanks a lot and really appreciated your kind help/assisatnce!
Hi @colin_mckibben, Thanks for your reply, Actually the integration itself is via REST regarding passing the parameters/configurations and so on. But also it’s maybe considering some UI modifications (if needed) so that I posted in the general one. Definitely your advise will be really appreciated, I’m looking to make this done either from UI, REST, or anything else inside or outside IDN .Thanks a lot @colin_mckibben over and over again!
For your first question, the Identity Now REST API provides two endpoints that you might find useful for obtaining information about access requests. list-account-activities can return information about access requests, and you can filter the results using query parameters to help you find the specific access request you need. access-request-status returns similar information. If you can’t find an appropriate filter to narrow down the results, then you’ll need to paginate through all of the results and use client side code to pick out the requests you need. Please see this post for more details on filtering access requests. Alternatively, you can use the search API to perform a search for access requests that meet your criteria. This might provide more useful results than the other two endpoints.
For your second question, I think you can you use the sources endpoints to get information about governance groups attached to the source. My IDN tenant is down so I can’t investigate this right now, but I’ll update this if I find a specific solution to getting governance groups for a source.
For your third question, I’m not sure what you mean by $plan attributes. Can you elaborate further?
And finally, if you want to track the status of access requests, please see my answer to your first question. The output of those endpoints can provide warnings, errors, and other data useful for debugging and tracking.
Hi @muhammedmustafa
The $plan variable are the Provisioning Plan object model, which our IDN and IIQ connectors use. I know this has been documented in other places at SailPoint and might make sense here too.
Loosely, the $plan is structured like this:
$plan
identity
accountRequests
op (account level operation - e.g. create, update, delete, enable, disable, unlock, etc.)
identity (account ID)
attributeRequests
op (attribute level operation - e.g. add, set, remove)
name (attribute name - e.g. sn)
value (attribute value - e.g. McGlennon)
As for the mention of the plan-initializer script, this isn’t something we allow usage of and seems to be a doc bug. You can ignore that. @colin_mckibben lets follow up internally on this.
We are in the process of creating ticket whenever admin requested for entitlement. We have defined the SIM integration and able to create the ticket in service now. But we are unable to populate the requested_for while creating the ticket. I see requested_for is part of $plan object but the value of the requested_for is coming from IDN is not recognized by service now. Is there any option to customize the $plan object and also sent identity name as requested_for.
You should be able to leverage Before Provisioning rules to be able to populate additional variables in the ticket, and have more control over variables like that.
SailPoint Expert Services has done that in the past and these are cloud rules so they’d need a review by them to get installed.
We’ve been able to use some of the suggestions here to help us and it’s been greatly appreciated. We worked with Expert Services and were able to figure out how to use the Create Profile area to add information to the ticket description as shown in the screenshot. There is one issue we have which has become a showstopper for our implementation and curious if anyone has suggestions.
Currently, the integration includes the entitlement name only in the description field, but our requirement is to include the entitlement description as well. After discussing with Expert Services, this was their reply “As we discussed the description of an entitlement cannot be sent along with the plan AND I don’t think there is a way to query this from a Before Provisioning rule also. Even we can’t get the Access Profile description also.”
So, does anyone have any suggestions as to how we could include the entitlement description (shown in screenshot) in the ticket description field during ticket creation?
Is there a resource for IDN that documents examples of Provisioning Plans? Either in XML or JSON format. I am trying to gather resources to help training those new to IDN.
.Thanks a lot 