# Blocking users from request centre **URL:** \ **Category:** SHF Discussion and Questions\ **Tags:** access-requests, identity-security-cloud\ **Created:** [September 3, 2026, 8:01am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360 "2026-09-03T08:01:40Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Menzowskii](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@Menzowskii](https://developer.sailpoint.com/discuss/u/Menzowskii)\ **Post date:** [September 3, 2026, 8:01am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/1 "2026-09-03T08:01:40Z")
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? ---
**Author:** ![suraj\_gorle](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/suraj_gorle/32/35158_2.png) [@suraj\_gorle](https://developer.sailpoint.com/discuss/u/suraj_gorle)\ **Post date:** [September 3, 2026, 8:10am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/2 "2026-09-03T08:10:21Z")
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. ---
**Author:** ![Deepak\_Chaudhary](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/deepak_chaudhary/32/34380_2.png) [@Deepak\_Chaudhary](https://developer.sailpoint.com/discuss/u/Deepak_Chaudhary)\ **Post date:** [September 3, 2026, 8:16am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/3 "2026-09-03T08:16:02Z")
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](https://developer.sailpoint.com/discuss/t/deny-all-access-requests-from-isc-request-center-ui/199709) ---
**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\ **Post date:** [September 3, 2026, 8:35am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/4 "2026-09-03T08:35:14Z")
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](https://documentation.sailpoint.com/saas/help/requests/segments.html)). 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](https://documentation.sailpoint.com/saas/help/provisioning/identity_states.html)). 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](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/access-request-submitted/)). 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](https://developer.sailpoint.com/docs/extensibility/event-triggers/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. ---
**Author:** ![Menzowskii](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@Menzowskii](https://developer.sailpoint.com/discuss/u/Menzowskii)\ **Post date:** [September 3, 2026, 10:09am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/5 "2026-09-03T10:09:44Z")
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? ---
**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\ **Post date:** [September 3, 2026, 10:23am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/6 "2026-09-03T10:23:37Z")
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. ---
**Author:** ![Menzowskii](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@Menzowskii](https://developer.sailpoint.com/discuss/u/Menzowskii)\ **Post date:** [September 3, 2026, 10:40am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/7 "2026-09-03T10:40:40Z")
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! ---
**Author:** ![Menzowskii](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@Menzowskii](https://developer.sailpoint.com/discuss/u/Menzowskii)\ **Post date:** [September 3, 2026, 10:42am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/8 "2026-09-03T10:42:02Z")
I will see if I can achieve anything with the workflow and let you know if its a success! ---
**Author:** ![Dianna\_Hutchcroft](https://avatars.discourse-cdn.com/v4/letter/d/91b2a8/32.png) [@Dianna\_Hutchcroft](https://developer.sailpoint.com/discuss/u/Dianna_Hutchcroft)\ **Post date:** [September 14, 2026, 4:01pm UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/9 "2026-09-14T16:01:11Z")
> [@punna0001](#): > > if your existing SoD automation is the subscriber under **Admin \>** We have the same requirement and have not had time to work on it. We are using the ServiceNow Service Catalog integration for requests and do not want ANYONE who isn’t an admin or Access Request Admin to be able to submit requests using the Request Center. Ideally we don’t want them to have the ability to do anything, including approve or deny requests, in the Request Center. Would be interested in what you find that works. ---
**Author:** ![uppala](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/uppala/32/34576_2.png) [@uppala](https://developer.sailpoint.com/discuss/u/uppala)\ **Post date:** [September 18, 2026, 2:37pm UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/10 "2026-09-18T14:37:06Z")
Hi @Menzowskii, The easiest approach is to create a scope and assign all access items to that scope. This solution can be easily modified in the future if you decide to allow users to request specific access items. Thanks, Mahesh ---
**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\ **Post date:** [September 18, 2026, 7:24pm UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/11 "2026-09-18T19:24:47Z")
You should just need to change an access request config flag for that > **[Limiting External Access Requests](https://documentation.sailpoint.com/connectors/servicenow/service_catalog/help/integrating_service_catalog/limit_ext_requests.html)** > > SailPoint Connectors Documentation ---
**Author:** ![Menzowskii](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@Menzowskii](https://developer.sailpoint.com/discuss/u/Menzowskii)\ **Post date:** [September 21, 2026, 9:12am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/12 "2026-09-21T09:12:44Z")
Hi Harish, I was able to create a workflow which indeed achieves both goals. The workflow is canceled if the request is for an employee with employee type = x for example. As well as automatically canceling if it detects that a SoD violation has occured! Thanks! ---
**Author:** ![Menzowskii](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@Menzowskii](https://developer.sailpoint.com/discuss/u/Menzowskii)\ **Post date:** [September 21, 2026, 9:14am UTC](https://developer.sailpoint.com/discuss/t/blocking-users-from-request-centre/221360/13 "2026-09-21T09:14:46Z")
Hi Dianna, Yes I was able to create a functioning workflow that automatically is canceled if a request is performed for a target user group (which the scope can be broadened to target many different user groups)