Lesson 1 of 5
Role design principles
10 min
Listen to this lesson
Most role problems are design problems. A role built by copying a power user, a role that mixes three jobs, a role with a wildcard because nobody knew the right plant: each was quick on the day and expensive for years. Contoso's conversion is a chance to fix this, because every ECC role has to be checked against the new apps anyway. Nadia, Contoso's security and GRC lead, starts with design before anyone opens PFCG.
Treat the role concept as a project
SAP's authorization course recommends treating the role and authorization concept as a project of its own, with five steps: preparation, analysis and conception, implementation, quality assurance and tests, and cutover. Analysis starts from the organization chart and a business process analysis, and SAP recommends a prototype to find design gaps before the full build.
- PreparationScope and teamProcess owners, security, IT; agree principles and naming
- Analysis and conceptionDesignProcesses, jobs and organizational splits; role catalog and authorization list
- ImplementationBuildSingle, derived and composite roles in PFCG in CMD
- Quality assurance and testsProvePositive and negative tests with test users in CMQ client 100
- CutoverGo liveRoles transported to CMP, users assigned, comparison run
Task-based and job-based roles
SAP's material describes two ways to model roles. One is to build each job as a self-contained role. The other builds small reusable roles for activities or tasks, restricts them by organization with derived roles, and combines them into composite roles that match a job. SAP describes the composite as the technical counterpart of a job role.
| Job-based (self-contained) | Task-based (building blocks) | |
|---|---|---|
| Unit | One role per job, holding every function | One single role per task, combined in composite job roles |
| Reuse | Low; similar jobs duplicate functions | High; one task role serves many jobs |
| Maintenance | A change to a shared task is repeated in every job role | A change to a task is made once |
| Segregation of duties | Conflicts hide inside large roles | Conflicts are visible as combinations of task roles |
| Risk | Role count stays low but roles grow too broad | Too many tiny roles if tasks are cut too fine |
Contoso uses task-based building blocks with derived roles for organization and composite roles for jobs. The task roles are sized by business activity, not by transaction: "post supplier invoice" or "create purchase order", not one role per app. That keeps the catalog small enough to understand and big enough to avoid conflicts inside one role.
Naming
SAP's course says every role type needs a unique identifier and suggests criteria such as country, business area (for example FI or CO) or application component. Role names can be up to 30 characters, and the system does not distinguish single from composite roles by name, so the convention must. Delivered roles start with SAP_ and can be overwritten by upgrades, so customer roles live in the customer namespace.
| Part | Meaning | Example |
|---|---|---|
| ZCMC_ | Customer namespace and company prefix | ZCMC_ |
| Type | JOB for composite job roles; none for task roles | JOB_ |
| Area | Business area or component | AP, MM, SD |
| Task | Business activity | INVOICE_POST |
| Organization | Organizational value for derived roles | _1710 |
Contoso's role naming convention (an example, not an SAP standard).
Segregation of duties starts in design
Task-based design makes conflicts visible, but only if the tasks are cut along the right lines. Contoso's rule is that no single task role may contain both sides of a known conflict: creating and approving purchase orders over $25,000, maintaining supplier bank details and posting payments, or creating and releasing purchase requisitions over $10,000. Conflicts can then only arise when a composite role or a user combines task roles, which is where the access risk analysis covered in the segregation of duties course looks for them.
Who decides
SAP's material assigns clear responsibilities: a cross-department team specifies roles and IT builds them; area managers, as data owners, are consulted and give final approval for user-role assignments; authorization administrators create and transport roles; user administrators maintain users and assign roles. The split is itself a control, the dual control principle covered in the fundamentals course. At Contoso, Dan owns finance roles, Maria owns order-to-cash roles and Nadia's team builds them.
What would you do?
A Chicago manager asks Nadia to "copy Ana's access" for a new AP clerk in company code 1810. What is the best response?
- Run the role concept as a project: preparation, analysis and conception, implementation, tests, cutover.
- Build task roles as reusable blocks, derive them by organization, combine them into composite job roles.
- Name roles so type, area, task and organization are readable; keep custom roles out of the SAP_ namespace.
- Data owners approve assignments; administrators build and transport; users are never copied.
Check your understanding · not graded
Lesson check
1. What is the main benefit of task-based roles combined into composite job roles?
2. According to SAP's course, who gives final approval for user-role assignments?
3. Why must a naming convention distinguish single and composite roles?
4. Which step does SAP recommend early to find design gaps?