Hi all,
We have a use case at a client in which a group of employees shouldn’t be able to request anything at all in the Request Center, and others shouldn’t be able to request access for them either. Access Request Segments don’t seem to solve this. Removing them from the nested IdentityNow SSO group (which everyone inherits via an AD group) is one option we’re considering, but not ideal, and will still allow others to be able to request access on behalf of them. How can we fully block Request Center access for this group?
Hi @Menzowskii ,
I don’t think Access Request Segments can fully meet this requirement.
Segments can control which access items users can see/request, but they don’t provide a way to completely block the Request Center for a specific group of users or prevent others from requesting access on their behalf.
You could use identity attributes and access controls to restrict what can be requested, but if the requirement is a complete Request Center block, I believe this would need a product-level capability or a custom workaround.
If anyone has found a newer ISC feature that supports this, it would be great to hear about it.
HI Menso,
however there is no such ootb functionality to achieve this, we can not disable the access request for some group of users, but there could be possibility by using the Segments capability given in the ISC or using the workflow. check for the reference -Deny all Access Requests from ISC Request Center UI
Hello Menso. Access Request Segments will not solve this. They control which access items the requester can see, not who can be selected as the recipient (Segments).
For active identities, I do not see a native per-group control that both blocks Request Center access and excludes that group as request targets.
If these identities can legitimately be treated as inactive, setting the lifecycle state’s Identity State to Inactive (short-term) removes them from Request Center identity picklists and My Team while keeping them in scheduled processing (Identity States). However, SailPoint has confirmed that access can still be requested for inactive identities through the API, so this is not a hard enforcement boundary.
For strict enforcement, I would use the Access Request Submitted event trigger. It runs before the normal approval chain and provides both requestedBy and requestedFor. Have the subscriber check those identities against the blocked population and return approved: false when either matches (trigger docs).
Because it is a response-required trigger, only one subscriber is allowed. If the tenant already uses it, add this check to the existing subscriber rather than creating another one (trigger types).
This still does not hide Request Center from those users. If they must not be able to sign in to ISC at all, restricting their ISC access at the IdP is the practical option, but that blocks all ISC access, not only Request Center.
Hi Harish,
Thanks for your response. We also did look to explore the Access Request Submitted event trigger option then have the workflow close the request. We already have another workflow that uses this event trigger which automatically closes a request if an SoD violation has occurred. Would we need to extend this workflow to then handle both use cases as the event trigger is limited one subscription?
I can’t remember exactly but I think the Access Request Submitted trigger also requires an action that is only available with a certain license to correct?
Hello Menso. Yes, if your existing SoD automation is the subscriber under Admin > Event Triggers > Subscriptions, I would extend that same subscriber. Access Request Submitted is a response-required event trigger, so only one subscription is allowed.
Add the blocked requester/recipient check alongside your existing SoD check and return approved: false for either condition. Otherwise allow the request to continue. That is cleaner than closing the request afterward.
On licensing, the event trigger itself is generally available to ISC tenants. The Business Plus licensing you may be remembering applies to Adaptive Approval Workflows, which is the separate per-access-item Workflow approval feature, not this tenant-level event trigger.
So if your SoD implementation already uses this event trigger, I would reuse it for both checks rather than introduce another approval mechanism.
Thanks for the response. I am going to try with a workflow as a workaround to automatically cancel the request if the user has x function value for example! I will let you know if I have any success!
I will see if I can achieve anything with the workflow and let you know if its a success!