Sharing IRM record links across Risk and Compliance Workspaces - how do others handle this?

[StormR]

Hi all,

If someone is viewing a Risk Event case in the Compliance Workspace and shares the link, the recipient can't open it if they don't have access to Compliance Workspace. Even though it's the same record, they'd normally view it in the Risk Workspace.

The workaround we've found

Manually changing the URL from:

.../now/risk/compliance/list/params...

to:

.../now/risk/risk/list/params...

(or vice versa) lets the recipient open the record in the workspace they do have access to.

Our business tends to share cases by link rather than just the record number. Using the number would let people paste it into the search bar and open it in whichever workspace they have, but link sharing is the habit and it's not going away quickly.

What I'm hoping to learn

1. Is there a setting or config that lets a shared link resolve to whichever workspace the recipient has access to?
2. Is there a recommended way to share IRM records across mixed workspace audiences without editing the URL?

[Vikram Reddy]

Hi @StormR,

There's no native toggle for this. Risk Workspace and Compliance Workspace are two separate Now Experience UI apps sitting on the same GRC content, each with its own route (now/risk/risk versus now/risk/compliance), so a deep link into one is meaningful only to someone who has that app. The platform has no concept of "resolve this link to whatever workspace the recipient can see."

The actual fix, and the one I'd build instead of relying on people remembering to edit URLs, is a Navigation Handler on the sys_navigator table for the risk event's table. This is the same mechanism ServiceNow uses out of the box to send sys_hub_flow records into Flow Designer instead of the classic form, so it's a supported pattern, not a hack. A few things to get right when you build it:

• Scope the handler to the correct table name, the one the Risk Event record actually lives on, not a parent or extended table it doesn't apply to.
• In the script, check the requesting user's roles, typically sn_risk_workspace.operational_risk_manager or sn_risk_workspace.IT_risk_manager for Risk Workspace, versus sn_grc.business_user for Compliance Workspace, and return the matching URL built from the sys_id.
• Guard against a redirect loop: bail out early with gs.nil() checks on the sys_id parameter, otherwise users with neither role (or both) can end up bouncing.
• Set the order field sensibly if there's any other handler already registered against that table, since handlers evaluate in sequence.
• Test with a user who only has one role and a user with both, so you catch the loop case before it ships.

Once that's in place, a shared link just opens wherever the recipient is entitled to land, no manual URL surgery needed. It's a config change, not code you have to touch again, and it survives upgrades better than telling your business users to hand-edit URLs.

Thank you,
Vikram Karety
Octigo Solutions INC