Administering Cloud EPM: The Platform Beneath the Business Processes · Module 6 · Users, Groups and the Role Model
Designing the group model
Lesson 68 of 201 · 2 min
The mistake: modelling the org chart. Forty departments, forty groups, most with identical access. WHAT ACCESS DIFFERS? TWO GROUPS WITH THE SAME ROLES ON THE SAME ENVIRONMENTS ARE ONE GROUP. The method, three steps. List the distinct ACCESS PROFILES — "Planning contributor", "Close process approver", "EDM data steward", "Read-only finance". Check each against the role mapping matrix. If two profiles produce identical cells, merge them. Name groups for the ACCESS they confer, not for the department that holds them. The naming convention, and there is a reason it matters beyond neatness. Groups appear in every access review and every audit. A convention that encodes the business process and the access level survives. A team name gets reorganized. EIGHT TO TWENTY GROUPS FOR A MID-SIZE MULTI-BUSINESS-PROCESS ESTATE. FORTY MEANS YOU MODELLED THE ORG CHART. Cross-environment groups, and this is the point rather than a side effect. One group can hold roles…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Administering Cloud EPM: The Platform Beneath the Business Processes, with a certificate on completion and a fourteen-day refund window.
In this module: Module 6 · Users, Groups and the Role Model
- 1What we are building
- 2The decision that does not feel like oneFree preview
- 3The access object model
- 4Predefined application roles
- 5Roles by business process
- 6Domain-level administrator roles
- 7Designing the group model
- 8Creating users
- 9Creating groups
- 10Policies for users and groups
- 11Assigning roles to groups
- 12Unassigning and offboarding
- 13Proving the model works
- 14What breaks
- 15Lab briefing: a role model for eight environments
- 16Lab solution walkthrough