** New version of ServiceNow Catalog for ISC v3.2 Released **
Version 3.2 of SailPoint’s ServiceNow Catalog v3.2 for ISC is now available for install.
What is the Problem?
Multiple new features have been introduced based on the feedback of customer, new features in ServiceNow and roadmap to improve the overall UI experience.
What is the Solution?
Following new features have been introduced in the version v3.2 in the SailPoint’s App for ServiceCatalog for ISC (IdentityNow).
Integrate with global search.
Skip user selection for non-managers/non-admins
Recommendations with Ignore
SoD details in approval request ticket
Approval Flexibility for OAuth2 connections
Relating ServiceDesk ticket for raised Access Request.
Improved Approval Flexibility with Auto approval options and standardised REQ/RITM states
Please refer to the product documentation for the detailed information
Who is affected?
Customers using SailPoint’s ServiceNow App to manage access.
Action Required
Detailed instructions while considering upgrade to this version is mentioned here:
Important Dates
This release is available for download from from ServiceNow Store effective May 8th’ 2024
Hey Kamesh, I was hoping at some point we might gain some more flexible options with the approval definitions. Right now we’re limited to either using the exact object name, or a “default” name like SAILPOINT DEFAULT ACCESS PROFILE DEFINITION
I’d like the ability to leverage some sort of search criteria to figure out which definitions need to be applied to a given request, for example
Definition name: Privileged AD Entitlements
Condition: source.name:“Active Directory” AND privileged:true
That way for some AD entitlements or access profiles, I can use one type of approval flow (manager followed by access owner for example) for privileged AD entitlements, but maybe for something less risky like distro groups, I can skip the manager approver and just send it to the access approver.
Correct me if I’m wrong, but there is currently no ability to bypass approvals completely, correct? It seems the approval rules are required to return an array of valid ServiceNow user sys_ids. If your rule does not return anything, the validation fails and the workflow is cancelled.
If I am an application owner and a user contacts me directly about getting access, I should be able to submit a request on their behalf and be able to approve it as the access owner.
I don’t understand why this would be an issue.
I am not attempting to approve my own access. “Requestor” is not the same person as Requested For, so there is no conflict.
Requestor is not even a ServiceNow field. The script include SP_SPNT_SNOW_INT_WORKFLOW_MLAUtils is referencing opened_by
This should be removed or at least made optional through a system property flag. What’s funny is that is an option depending on what type of approval rule you have chosen.
You cannot bypass the opened_by being the same as the returned approver for these approval rule types
ServiceNow Group
ServiceNow Script
IdentityNow Governance Group
But you can if you use one of these approval rule types
ServiceNow User
IdentityNow Owner
IdentityNow Manager
You have the ability to allow the person who opens the request to still be an approver by checking true for the system property x_sap_intidn.self_approval_auto_approve.
The latter types of approval rules call a different validation function. Why is there a difference in how they’re evaluated?
Is there any further documentation around setting up the default approval group?
We’ve populated the group “SailPoint Access Governance Group” with active users, however the request gets rejected with error “missing approvers in definition and ServiceNow default group.”
Does the group require some other setup or ServiceNow access role to function?
Are those users mapped properly to ServiceNow users?
No other setup is required. I assume we are missing some other information here. Can you please raise a support ticket so that we can investigate and guide you accordingly. Please tag this discussion in the ticket.