You can use segments to limit specific access items to a targeted set of users. Segments represent a set of identities that have been grouped based on identity attributes. Admins can add access items to segments to make this access visible only to users included in these segments. When a user in a segment visits the Request Center, they are presented with access items defined in their segment and access items that are not included in a segment. Users who are not part of a segment can only view access items that are not part of a segment.
Hello,
Please can you make the document more clear, as it seems many people are getting tripped up on it.
Users are presented with access items defined in their segment and access items that are not included in a segment.
Please can you emphasize the part in bold above. That if a role or access profile is not part of any segment, then users will be able to request it.
You can add and save up to 50 access items to a segment at a time
Many people seem to interpret this as segments can only contain up to 50 access items.
Please can you emphasize that segments can contain X (is there a limit?) access items, however only 50 can be added at a time
i.e. it is possible to have a segment that contains 150 Roles (for example) but you need to do this in a minimum of 3 separate steps. Add 50 roles, then add next 50 then add next 50.
Could you better define the steps to add the Identity criteria, and the limitations around it in the " Defining Segment Identities" section.
Step 5 currently reads:
Select Add Criteria for each identity attribute and value combination you want to add to the segment. As you do this, the table lists identities that meet the membership criteria.
Currently, when testing this, there is a limitation that you can only add 1 value per IdentityAttribute, and that once you have chosen one, that IdentityAttribute is no longer available to choose. So the segment criteria only handles the AND case, and does not handle the OR case between attributes.
For example, if your requirement was "Country equal ‘USA’ OR ‘Canada’ " that would need to be done as 2 separate segments, even if all the remaining values were the same.
Hi Geoff! Thanks, as always, for your great feedback.
I’ve created SAASDOCS-8116 to clarify the steps and limitations for adding identity criteria to segments. We’ll let you know when we’ve updated those docs.
I am missing explicit information on how segments affect the functionality of requesting access items for other users.
From what I can currently see, as long the requester sees an access profile it can request it for anyone (if the functionality to request access items for others is enabled of course).
Hi @adamian! Thanks for taking the time to give feedback. I’ve created SAASDOCS-8667 to review our segment docs and the access profile request behavior. We’ll update this thread when we’ve finished our review.
Hi Andrei! We have not included explicit information on how segments impact requesting access items for others because segments don’t really change that functionality.
Segments apply to the requester and to access items. They do not limit who the requester can request for, and they do not limit for whom the requester can request specific things. If the requester can see the items, they can request them for anyone they are authorized to request on behalf of.
Hi @BeckyJorgensen, thanks for the answer.
I think adding one extra sentence will make it clear that this has no impact and that is the intended behavior.
The first sentence in the documentation says:
You can use segments to limit specific access items to a targeted set of users.
As I read this, I may think that “access items” can not be used by any users that are not part of the specific segment.
So the more precise sentence could be
You can use segments to limit request to specific access items to a targeted set of users.
and that is why I think adding an explicit information about the impact would be helpful.
for each identity attribute and value combination you want to add to the segment. As you do this, the table lists identities that meet the membership criteria.