Restricted ER cases: the requester loses access but keeps getting notifications they can’t act on

[Kohei Tominaga1]

Hi, Community

In HRSD Employee Relations, restricting a case removes the requester’s access — yet the notifications, including the resolution notice and the request to accept the resolution, keep going to that same requester.

I’ve raised this with both ServiceNow Support and the Impact team. To their credit the answer wasn’t simply “by design”: I was told these are high-confidentiality cases, so access is narrowed to the minimum necessary.

But I don’t find that convincing.

As far as I can confirm, an ER case doesn’t expose investigation content to the requester even without restriction — they only see the case number, what they submitted themselves, and additional comments; work notes never surface. If the sensitive material never reaches them in the first place, “we must cut their access to protect confidentiality” rests on a premise that doesn’t hold.

And even granting it, the real question goes unanswered: if this person should no longer have access to the case, why does the platform keep notifying them about it?

From the requester’s side: they get “Your case is resolved — please review and accept,” click the link, land on the portal, and are told they have no access. They can’t accept. They can’t even tell what case it is. The predictable result is a complaint. For a platform whose central promise is employee experience, I can’t see how this holds together.

To be clear, I know I can add a “not restricted” condition and might suppress the notifications. That isn’t the point. The point is whether this is the intended OOTB behavior and what the reasoning is — because “it’s complex, we’ll work around it” is not something I can put in front of my product owner and process owner without losing their trust.

So:
- Does anyone know the design intent?
- Is there an official position, or any roadmap to change it?
- If you’ve hit this, how did you reconcile it — not just technically, but in what you told your stakeholders?

I’m not here to pile on. I want the reasoning behind “by design,” because right now I can’t give it to the people relying on me to have it.

[SupriyaWaghmode]

Hello @Kohei Tominaga1 , 

The Design Intent (Why it works this way OOTB)

The conflict stems from two different engineering teams at ServiceNow building two different features that do not natively talk to each other: Security (COE Security Policies) and Communications (Notifications/Activity Stream).

• The Restrict Action is a "Kill Switch": When a case is restricted, the platform applies a strict ACL or COE Security Policy. It treats the case as a data liability. The system's primary directive changes from "help the employee" to "protect the organization from a legal/compliance breach." It completely blinds the requester to prevent accidental data leaks.
• Notifications run on standard Task logic: OOTB notifications for resolutions are tied to the generic sn_hr_core_case table state changes (e.g., State changes to Resolved). These notification engines simply check: Is there an Opened For/Subject Person? Send email. They do not run a pre-flight check to see if the recipient currently has read access to the Portal page.

The "By Design" Argument you can give your stakeholders:
The system is intentionally built to prioritize zero-leak security over user experience in high-risk scenarios. If an HR agent accidentally leaves a highly sensitive file, name, or Work Note visible in a related list or description, restricting the case is the emergency brake. The platform assumes that an absolute data lockdown is safer than a broken portal link.

2. Official Position and Roadmap

ServiceNow acknowledges this gap. Historically, their official stance was to treat restriction as an administrative exception rather than a standard lifecycle status.

• The Current Reality: There is no automatic OOTB mechanism that disables notifications the moment a case is restricted. It remains a known limitation of strict data segregation.
• The Roadmap: ServiceNow has been actively moving toward Configurable Workspace Security and unified signalling. However, because ER processes vary wildly by global legal jurisdictions (e.g., GDPR vs. US labour laws), ServiceNow deliberately leaves notification suppression to implementation partners and platform owners rather than forcing a hardcoded rule OOTB.

3. How to Reconcile this with Stakeholders

To maintain trust with your Product and Process Owners, you must shift the conversation from "ServiceNow is broken" to "ServiceNow gave us a secure foundation, and now we must configure the corporate policy layer."

Here is the exact narrative to deliver to them:

"ServiceNow’s Out-of-the-Box behaviour enforces absolute data security. When an ER case is restricted, the system treats it as a legal lockdown, stripping all portal access to eliminate any risk of data exposure. However, the system's standard communication engine doesn't automatically know a case has been locked down. Leaving this OOTB means employees get emails to link they can't open, creating a poor experience.

To fix this, we are going to align the system's communications with our internal ER policy by introducing a minor configuration to silence these specific notifications on restricted cases."

4. The Technical Alignment (The Fix)

To make your system behave logically without creating a heavy customization footprint, implement these two targeted fixes. This proves to your stakeholders that you can easily bridge the gap.

Fix A: Update the Notification Conditions

Add a condition to your ER Resolution notifications to check the is_restricted attribute (or your specific restriction field/flag).

• Condition: Restricted | is | false (or Assignment Group | is not | ER Restricted)
• Result: The employee will never receive a dead link.

Fix B: Leverage the "Resolution Template" / Manual Communication

If an ER case is restricted but still requires employee acknowledgment:

• Train ER Agents to use a specific HR Letter/Document Template or a manual, heavily redacted email via the platform that does not include a portal link.
• The agent can state: "Your case has been resolved administratively. Due to the confidentiality of this matter, details cannot be viewed online. Please reply directly to this email if you have questions."

Please mark helpful / Accept the solution if resolves your query.

Best Regards ,

Supriya Waghmode