Description
We’ve improved the details provided to access request approvers, giving them the information needed to make better decisions more easily!
We’ve improved the details provided to access request approvers, offering enhanced information to support their decision-making process. The updates now include essential elements such as source and application names, allowing reviewers to easily understand the context of each access request. By improving the details overlays we can provide comprehensive information about requested items, ensuring reviewers have the necessary context for informed approvals!
Expanded info in Details view
- Entitlements now include source name, native attribute-value of the source entitlement, and the privileged flag, where applicable.
- Access profiles show the source name and any associated applications.
- When metadata is enabled for the tenant and configured for roles or entitlements, those attributes and values will also be shown.
The Identities tab of the approval details now includes the email address of the target user as an automatically displayed attribute, so customers will not need to use a public-identities-config attribute to show that value.
Identity email shows by default
Who is affected?
All customers!
Important Dates
- Sandbox: Enabled now.
- Production: rollout week of Oct 7.
5 Likes
In the future, I’d like to see the entitlements listed in the Access Profile for the request
3 Likes
Looks good @jennifer_mitchell! Thank you 
Regarding this: I didn’t know that the email address of the access recipient wasn’t already always visible, but based on your announcement it sounds as if before customers were able to choose whether or not they wanted to have the email visible, and they could make this choice by configuring it as a public-identities-config attribute or not, and it sounds that because SailPoint notices that the majority of customers want this email attribute to be visible, they save the customer from performing this step by having it there directly anyway.
In general I am opposed to such a strategy as you have basically removed an existing choice from the customer. Those who don’t want to have it visible cannot configure it anymore right? As alternative solution I would suggest to keep it as is, and instead ensure that the blank environment new customers get have email configured as public-identities-config by default. This way you remove the step of needing to configure this for the majority of customers who want this functionality, whilst still facilitating for those customers that don’t want this attribute to be visible for approvers (perhaps for compliance or security reasons). Although the effect of the strategy in this case could be low, I nevertheless want to bring this to your attention
In addition, an improvement would be to create documentation on the public-identities-config functionality and make it configurable in the UI for more awareness and user friendliness.
This is similar to a previous announcements where SailPoint added more out of the box identity attributes to save many customers a step, whilst not allowing the removal of these identity attributes for customers to which these don’t make sense.
In short: One size fits nobody. Keep supporting configuration is good
I appreciate the perspective, Angelo.
In this case, our goal is, as you say, to serve the majority need, and also to drive consistency in how we show identity data – certifiers get email address by default but approvers did not, so customers who wanted it in approvals had to use one of their 5 public-identities-config attributes to display it, which also meant email displayed twice in certs (once built in and once because of that attribute).
I can see your valid argument for us to consider (long term) allowing all of this to be configurable, but I hope the majority of our customers will appreciate the improved consistency and flexibility (for using their public-identities-config attributes for other key data) of this change.
1 Like
Thanks for that input. Yes, I know more details about the access behind the requested access (APs and entitlements behind roles, entitlements behind APs) is a further enhancement that would be highly desirable. It’s on the list for future work.
If you guys are in the space of updating the UI of the request center and approvals in general, can you please just finally deliver on this idea? Note that it’s 3 years old. https://ideas.sailpoint.com/ideas/GOV-I-1567
It’s an actual issue people are having that can be easily solved, unlike most of the stuff I keep seeing updated. I haven’t seen a single approver misunderstand who they are approving access for or what access they are approving, but I guess more clarity never hurts.
Edit: I also want to say I wholeheartedly agree with Angelo’s sentiment of “One size fits nobody. Keep supporting configuration”. We’re happy to see new updates that help other tenants even if they aren’t something we directly need, but don’t take away things we’re using/force us to use things we don’t want to in the process.
Thank you for your feedback. As noted in the linked idea’s comments, there are nuances to it that make it less easily solved (with an accurate solution) than it might seem. But governance group approver visibility in My Requests remains at the forefront of our awareness, and I believe that some work scheduled for the upcoming quarter will unblock this much-desired enhancement.
In the details section on the access request approvers page, approvers can no longer see access expiration/sunset date submitted by the user.
This has currently broken our processes as the approvers are rejecting all requests assuming user hasn’t set any expiration date.
I’ve attached the screenshot of older details page that shows where approvers would see the expiration/access sunset date field.
1 Like
Oh wow, that actually explains why I just got contacted by a confused user who was denied access and told they needed to add an expiration date to it. They were wondering where in the process they messed up on setting the expiration date and I had to tell them the approver probably messed up, since it was clear to me there was an expiration date on the request.
So this is already affecting users and needs to be fixed please!
Thank you for bringing this to my attention! I will contact the team immediately to have this addressed ASAP.
3 Likes
We have temporarily rolled back the change to the Details tab of approvals so we can address the inadvertent removal of the expiration date. The identity email address change remains in effect and will roll out to the final batch of customers later today. We expect to (re-)release the updated Details tab next week with the expiration date, which will appear near the top of the list of data (when one is specified) so it will be visible at first glance even with the newly added information.
Thank you for alerting me so we could be responsive to this issue.
2 Likes
Thanks Jennifer for the update.
We observed one more thing related to Access item Description - in the same approval page, Approvers can no longer see the complete description of the Access Profile. Approvers are only able to see the top line of the description, are there any new character limits in the description?
@gopigummadifmc I’m unclear on what you are seeing. In the card itself, you will see only the first line or two of description text (and that will cut off at the first newline, if one is specified in the description), but the overlay should show the entire description, and my developers’ testing shows that we are displaying the entire description in that overlay. If you can elaborate, I will work to confirm your scenario with my team.
Hi Jennifer, please refer the attached screenshot for additional context.
Thank you Gopi. I have shared this with my team. The update we are working on should fix this issue.
There has unfortunately been another delay with a portion of this enhancement rollout. The Details overlay piece has had to be rolled back and will be held back indefinitely as we work to resolve a couple of issues that have surfaced. I will post a whole new announcement when we are ready to push that enhancement out again so we don’t keep messaging into an old thread about new changes.
As before, the identity details update will remain in place for all customers.
