Sometimes I observe announcements that mention recognizable problems and then a solution that does not actually solve those problems. It seems this is such an announcement to me.
One reason for this is that when looking at the requestable roles in the SailPoint Access Request Center, which sources it would grant access to. The solution would be to for the UI to specify this information and allow users to filter on requestable roles granting access to a specific source. The search API does not support querying for roles based on such criteria, so an AI would not be able to do that either. You could ask an AI this anyway and if the AI is fully correct and will not hallucinate, it would have to call a lot of API calls to truly answer this question. Both AI and those API calls would then be a waste of electricity for a problem that can simply be solved efficiently and 100% correctly if you turn off the mentality of “The solution MUST be using AI, regardless of the problem”.
One reason I hear and see from customers is access requests that are stuck in approval flow where the approver is a governance group. The requester/recipient are not being shown the current approvers at that point, and only see the governance group name. So they don’t know who to ping to ask to look at the request with priority. SailPoint says that some customers don’t want the requester/recipient to know who the members are. The clear solution would be a configurable setting mentioning whether this should be visible or not allow different customers to make different choices., and for the ISC request center to then properly show the members. I don’t see how the solution would solve this here. Respect customers who don’t want this information to be known while allowing other customers to configure it such that current approvers are visible to the recipient/requester (taking into account that governance group members might have reassigned the approval request, or it might have been escalated to other approvers). See this 4 year old idea here, which is still not implemented: https://ideas.sailpoint.com/ideas/GOV-I-1567
This is also an easy one. Navigating between pages in ISC has been made more difficult since SailPoint removed the navigation bar from many pages. See the request to add it back here:
All of the given examples above explains why custom UIs are being built. To show which roles point to which sources. To show which approvers you are waiting for in your access request. To allow more easy navigation between different ISC objects.
In addition SailPoint does not have read-only admin access, If people want to just see the notification templates in the ISC UI for example, you would need to have full org admin access. So this also could trigger users in building their own UI to mitigate this big security risk. See this top voted, but already 4 year old idea here: https://ideas.sailpoint.com/ideas/GOV-I-737
Kind regards,
Angelo