Guidance: GRC Workspace Page Variant Architecture & Multi-BU RAM Strategy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
30m ago
Hi Community,
As an alternative to the earlier question of using custom workspaces, we would like to seek inputs/advice on using page variants as a more viable solution.
[Current Context]
Workspaces/Roles: BU #1 currently utilizes the standard GRC: Risk Management Workspace across three roles (Business Op-Risk Manager, IT Risk Manager, Operational Risk Manager).
- Entity Hierarchy: BU #1 previously defined and locked the Root Entity Class mapped to RAM_A. Organizationally, BU #2 is the parent of BU #1 and oversees multiple child departments requiring future RAM variants.
[Questions]
Q1. Role & Page Variant Strategy
To onboard BU #2 (New Business Op-Risk Manager, New Operational Risk Manager), should we:
- Add custom roles and targeted UI Builder (UIB) Page Variants with Audience conditions directly to the existing GRC: Risk Management Workspace?
- How do we best structure variant ordering and audiences to prevent routing collisions?
Current config in GRC for BU #1:
1. Business Op-Risk Managers
2. IT risk manager
3. Operational risk manager
To add/create custom roles under GRC: Risk Management Workspace for BU #2:
4. Business op-risk manager #2
5. Operational risk-manager #2
6. IT risk manager #2
Q2. Entity Class Hierarchy Restructuring
As BU #1 currently holds the Root Entity Class tied to RAM_A, what is the best practice for re-parenting BU #1 under a new BU #2 Root Entity Class without invalidating active risk assessments or scoring configurations?
Q3. Multi-RAM Architecture
How should Entity Classes and Risk Assessment Methodologies (RAMs) be structured so BU #2 and its future sub-departments can run distinct RAMs independently alongside BU #1?
Thank you, in advance for your guidance!
