We’re streamlining the access request flow for customers who have chosen not to use Applications!
Until now, users at customer organizations that haven’t configured applications for access requests have seen an empty Applications tab in the Request Center, with instructions to click Access Items to view requestable items.
Note: Any user with available access request recommendations will still see that tab as their initial view in the Request Center.
Action Required
No action is required to enable this new behavior. If no applications are configured for access requests, the Applications page will automatically be suppressed.
Important Dates - UPDATED
This is being rolled out in the next couple of weeks:
Sandbox: Thursday, June 5, 2025
Production rollout: June 19-24, 2025 (Due to a scheduling oversight, the production enablement was delayed a week from the original plan.)
By RSVP’ing to this event you will be reminded of this release prior.
Any chance this could become a configuration flag to make Access Items the default, even for those of us who do have applications configured? Sort of linked to: https://ideas.sailpoint.com/ideas/GOV-I-4279
This is great but i see lots of time issue while creating application , AP attached to application is sometime visible and sometimes its take lot of time and we don’t have any clue what is going behind the scene and when these AP will be visible.
This was a pain until we had applications turned on in fact. I am glad to see enhancements that are so specific. Please do share what you have in store for us all next.
I included a note in the announcement above that for users who have recommendations, those will still show first. Not all users will always have recommendations, but when they do, they are the items our AI recommendations engine has identified as appropriate for the user based on an analysis of their access and the access of identities similar to them in various ways.
That Recommendations tab is not new - it has long been how we show access request recommendations. If it is new to you, it is likely that you have seen it before because you did not have recommendations identified for you.
Simon -
If you are in early stages of implementation and are in a data state that is not ready to have recommendations enabled, you should be able to request (through your SailPoint representative - CSM, account manager, services consultant, or if none of the above through a Support ticket) to have the recommendations product flag disabled for you. Likely you are in a suite level that includes it so it was auto-enabled for you on tenant creation.
We see the effects in our production environment correctly
Unfortunately we also observe the recommended items first. It is also not clear that the recommendations are recommended by an AI, so end users might think it was personally recommended by a human like an application manager. This can trigger access request creep, adding unnecessary actions for approvers to reject, and if rejected wrongly, it can trigger privilege creep.
Knowing that we prefer to have filters in the request center such as filter on roles that relate to a specific source, I recommend SailPoint to not have a special tab for recommended access, but instead just show the access items directly, allowing people to search for roles, and apply a filter, which can include the filter “Only show recommended roles” similarly to how it can include the filter “Only show roles regarding source A” or “Only show roles with metadata B”.
Now our end users still have to click on a different tab to be able to search for roles. If they now type a query and hit search, they will get the wrong items, (only recommended roles) and they would then need to click on roles, and then they discover that the query has disappeared, requiring them to type it all over again.
You could tell them to just request the recommended roles (which can cause unnecessary work) or to just hit ignore on these recommended roles. But in the latter case this triggers an “are you sure, if you hit ignore, we won’t recommend this access item again.” message, which might deter users from hitting ignore just in case they ar e actually interested in the recommendations several months later.
We’re streamlining the access request flow for customers who have chosen not to use Applications!
