Enhancement: Mandatory End Date and Max Duration on Access Requests

Announcements Product News
, ,
21

Is it possible to add to the settings of the tenant the option to disable this feature?

22

Not at this time. We hoped to lessen that potential confusion by end users by retitling from ā€œexpiration dateā€ to ā€œend dateā€. But there is still an idea you can add your input to for being able to disable the feature entirely: https://ideas.sailpoint.com/ideas/GOV-I-2770

23

Super nice feature, been waiting for this for a long time!

I do have one question, what happens to existing assignments that previously had NO expiration date set when requesting?

You mentioned this: Max durations will not be applied to existing assignments. However, any future changes to existing assignment dates will have to comply with the max duration.

But the example referred to existing assignment with end date set. The reason why iā€™m asking is because weā€™ve got a service account that should have access to that permission at all times but for regular user we want to force JIT.

24

An existing assignment that currently has no end date will continue to be left alone. If someone tried to change that assignment to set an end date, that new end date would have to follow the max duration requirement.

25

This approach was implemented in IIQ 2022 and imported hourly-based JIT provisioning. Our organization is using this solution seamlessly and There are a few hurdles we overcame.

Thanks,

PVR.

26

@ndanjou - thank you for the input on the UX here. Weā€™ve had a couple of others express similar early misunderstandings in their user populations. I am going to work with my UX and docs teams this week to work through some clarifying text changes we may be able to apply to mitigate the end user challenges.

27

Weā€™ve gotten some early input from a small number of customers that their end users are experiencing some confusion about the intent of the End Date and Time fields and are causing themselves problems by misusing the fields.

To mitigate this confusion, we are going to change a few text components on the Request Details overlay (where date/comments are entered):

  1. End Date and Time label will be changed to Access End Date and Time.

  2. We are adding text to the line under that label that explains that when specified, this is the date/time access removal will start. (Phrasing will vary slightly based on whether it is optional or required, but both with provide that context.)

  3. We are editing the instructions at the top of the overlay to explicitly explain that the date/time are about revocation.

  4. We are fixing the instructions so they wrap instead of truncating with ā€œā€¦ā€ if the userā€™s screen is too narrow.

We expect to be able to roll that update out next week.

1 Like
28

Would we expect the requestable objects endpoint to be updated to display if the item has a max duration / required end date? If not - are there endpoints that will display that for users in a request context?

29

Hi @adunker ,

We have not yet been able to get Search data updated with these configs, though it is on our backlog of enhancements weā€™d like to do, and requestable-objects comes from that Search. In our UI, we have built retrieval of that config as a secondary call to the endpoints that contain the request-config for the specific object, as the user adds each item into the request:

So if you are trying to do that in an external process as well, I think thatā€™s the path to follow.

30

Thanks - I think it will be important to get it into the requestable-objects endpoint because the role & access profile endpoints require high user levels, where as requestable-objects is available to the basic user level.

31

I just noticed the new UX. I think is much clearer to end users, thank you!

32

amazing Info and looks clean UI

33

Iā€™m happy with this enhancement and it has been useful but it does seem like this verbiage is confusing people ā€œAccess removal will automatically begin at the selected date and time.ā€ Can it simply say ā€œAccess will be removed at the selected date and time.ā€?

The mention of ā€œwill automatically beginā€ is making end users think access will begin at that time. While it may make sense to those of us who eat, sleep, breathe SailPoint, from the perspective of the end-user who is reading quickly and in a rush to request access, it is confusing and unnecessarily verbose.

34

Weā€™re trying to thread a complicated needle here. In truth, what it does is adds the request to the queue for provisioning. If thatā€™s being done with a direct connector, then your statement ā€œbe removedā€ is generally accurate. If itā€™s creating a manual task or a ticket in a ticketing system, it may or may not ā€œbe removedā€ at that moment ā€“ it could take as long as the person it is waiting on takes.

We can take your suggestion under advisement and consider whether we can simplify, but thatā€™s why we didnā€™t just use that phrase in the first place.

1 Like
35

We have received 7-8 tickets and complaints with increasing aggression/frustration from people who have misunderstood the new UI thinking it meant access will begin on the set date. Iā€™m surprised more of your customers are not experiencing this.. or maybe not yet?

Please reconsider the UI :innocent: Thank you!

36

Here is an example of the error people are reporting.. they submit a request with a date in the near future (within half an hour) believing it to mean thatā€™s when access begins. The approver goes to approve.. but the access request is already expired and so errors out.

image
image591Ɨ307 62.1 KB

37

Thank you for the feedback. We actually have a change coming that will reorder the fields to put Comments at the top of the panel in Request Center. When comments are required but end dates or not (which seems to be the primary source of the confusion), the Save button on the panel will become active immediately after comments are entered, which we hope will reduce the misunderstood use of the date field. We will continue to monitor your input and customer usage, and as necessary, we will explore other adjustments that may be needed in the future.

Also, in the very near future, approvals will auto-expire when they arrive at the scheduled end date before being approved, so this error will also not be an issue.

1 Like
38

Hi @jennifer_mitchell

We are also facing lots of issues similar to Renuka. Is there way to completely disable end date fields for accesses for whom ā€œend dateā€ is not mandatory?

39

There is not currently a way to disable the end date fields. The reordering of the fields is coming later today, I believe. Letā€™s see if that improves the issue.

We will continue to monitor and consider other options as needed, such as hiding the date fields behind a toggle if they are not needed. I hesitate to do that too quickly because it does create more clicks for people who want to supply dates, but itā€™s an option we can look to if needed.

1 Like
40

I think by hiding the fields behind a toggle, what people would be looking for is a toggle on the access profile configuration to hide the option. Not a toggle in the request UI to reveal the field. That way it puts the admins in control of whether users even have the opportunity to mess it up/be confused.

3 Likes