Risk workspace
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-29-2024 03:58 PM
We are planning to roll out the Risk workspace to the users. What we have observed is that access to the Risk workspace is controlled by roles like 'sn_risk_workspace.operational_risk_manager' or 'sn_risk_workspace.IT_risk_manager'
Both roles contain the role 'sn_audit.manager', which gives the user access to the audit module.
Is there a way to give users access to the risk workspace without giving them access to the audit module? I don't want to remove the 'sn_audit.manager' role from the 'sn_risk_workspace.operational_risk_manager' role, as this is a customization.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-29-2024 05:45 PM
Hi @rajeeshraj to access workspace these are the only roles which should be provided
Regards,
Prasanna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-29-2024 06:48 PM
Thanks, but the problem is that these workspace roles contain Audit roles, which gives the risk users access to the Audit module.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2024 05:26 AM
Hmmm - all of the risk workspace roles contain one of the audit roles. Unless you want to exclude this from ALL workspace users, you are going to need to do customization.
If you are talking about giving access to someone that is a risk owner - then you may want to consider the sn_risk_workspace.business_op_risk_manager role. But even that one has the sn_audit.user role contained within it. If you really don't want them to access audit, AND no one else is going to use that role; you could remove the audit user role from the workspace role.
Suggestion - if you plan to try and remove the audit role from the workspace role, test it out. Bring up two instances one withe audit role contained and one without - and then see what access is denied.
If some users need the audit access, then you will need to create a new role and edit ACLs accordingly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2024 02:41 PM
My understanding is that, in the future, ‘Workspaces’ is the recommended User Interface for the second-line (compliance and risk) and third-line users instead of the ‘classic view, ' Regardless of whether they are managers or staff in the second or third line.
I am leaning toward removing the Audit role from the workspace role, as the Audit role will be provisioned to 3rd line through a group