The right access for every person, and nothing more.
Who can post a journal, release a payment or change a supplier's bank account? In SAP Cloud ERP that's decided by business roles. Design them well and your auditors are happy, your people can do their jobs, and you don't pay for licences nobody needs. We design, build and look after your roles, from the first workshop to every upgrade after go-live.
Four building blocks decide what anyone can do.
SAP Cloud ERP doesn't use the old authorisation objects and profiles of on-premise SAP. Access is built from four blocks, and SAP delivers most of them ready-made. The work is in combining them to fit your organisation.
A person
Every employee who signs in, linked to their record in HR or the employee master.
A job
What a job needs, built by you from SAP's catalogs. A user can hold several roles.
A set of apps
Delivered and maintained by SAP. Each catalog groups the apps for one task and is designed to avoid conflicts.
A limit on data
Which company codes, plants or sales areas a role can see or change, and whether it can only read.
Start from the jobs, not from SAP's demo roles.
SAP ships standard roles so you can try the system. They're for demos and testing and should never be given to real users in production: they're too broad, and they cost you licences. We build your own roles from SAP's catalogs, one per job, mapped to how your teams really work.
We start from SAP's list of apps and the catalogs they belong to, run workshops with each department, and agree a role matrix your managers can sign off. Each role also gets its own launchpad space, so people see only the apps they use.
Your role design decides your licence bill.
In SAP Cloud ERP, every app belongs to a catalog, and every catalog has a licence category. A user's licence type follows the most demanding catalog in their roles. One careless app in a role can move a whole team to a more expensive user type. We design roles with the licence category in view from the start, and check it again whenever a role changes.
| Who | Typical access | What to watch |
|---|---|---|
| Professional users | Finance, sales, procurement and planning teams who create and change documents. | Give each team only the catalogs its job needs. |
| Operational users | Warehouse, production and service staff doing focused, repetitive tasks. | A single professional catalog can move them to a higher user type. |
| Self-service users | Employees who approve, request or look up information now and then. | Keep their roles to approvals and self-service apps. |
| Technical users | Interfaces and integrations that call SAP's APIs. | Communication users are set up separately from people. |
SAP's user types and their names change with SAP's licensing model. We check your design against your current SAP contract and give you the count for each type before you sign.
No one should be able to create a supplier and pay them.
SAP designs its catalogs so that a single catalog doesn't combine conflicting tasks. Conflicts appear when roles combine catalogs, or when one person holds several roles. We define the conflicts that matter to your auditors, check every role and user against them, and document the controls where a small team means one person must do both.
For companies that need more, SAP Cloud Identity Access Governance adds automated risk analysis, access requests with approvals, and regular access reviews by managers. We help you decide whether you need it.
One sign-in, managed where your people already are.
SAP Cloud ERP signs users in through SAP Cloud Identity Services, which can hand over to the directory you already use, such as Microsoft Entra ID. Your people use their usual company sign-in and multi-factor authentication. When someone leaves, disabling them in your directory closes their SAP access too.
- Your employee opens SAP.
- SAP Cloud ERP asks who they are.
- SAP Cloud Identity Services passes the request on.
- Your directory checks their password and MFA.
- They're signed in with their usual company account.
Roles need looking after, especially at upgrades.
SAP adds and changes apps in its catalogs with every release. After each upgrade, SAP lists the role changes waiting for you, and someone needs to review them: some add useful new apps, some need a restriction set before people can use them. We do that review for you, as part of every release.
Data protection matters more every year. Sri Lanka's Personal Data Protection Act brings its compliance obligations into force from 1 January 2027. We help you limit who sees personal data, keep it out of custom fields that aren't logged, and use SAP's tools for blocking and deleting personal data when it's no longer needed.
Upgrade role review
New and changed apps reviewed and approved after every SAP release.
Joiners, movers, leavers
A simple process so access follows people as they change jobs.
Access reviews
Managers confirm their team's access every quarter or half-year.
Personal data
Access to employee, customer and supplier personal data kept to those who need it.
Audit evidence
Role matrix, conflict rules and review records ready for your auditors.
Emergency access
A controlled, logged way to give temporary extra access when something breaks.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Straight answers.
Can we just use SAP's standard roles?
Only for demos and testing. SAP's standard roles are broad examples. In production they give people more access than they need and can push users into a higher licence type. We build your roles from SAP's catalogs instead.
How long does role design take?
It depends on how many jobs and companies you have. For a mid-sized company, role design runs alongside the project for several weeks and needs time from each department head. Starting early avoids a rush before go-live.
Can our existing ECC or IFS roles be copied across?
Not directly. SAP Cloud ERP uses a different access model. Your current roles are still useful as a starting point for who does what, and we map them to the new catalogs.
Do we need SAP Cloud Identity Access Governance?
Many companies manage well with clear roles, conflict rules and regular reviews. Larger or regulated companies, or those with strict audit demands, often find the automated risk analysis and access requests worth it. We'll help you decide.
Can we keep using our Microsoft sign-in?
Yes. SAP Cloud Identity Services can hand sign-in over to Microsoft Entra ID or another corporate directory, so people use the account and multi-factor authentication they already have.
Know who can do what, and prove it.
In one session, we review your current roles or your plans for them, show you where the access and licence risks are, and propose a role design your auditors will accept.
- Role matrix by job
- Licence impact of each role
- Segregation of duties rules
- Single sign-on with your directory
- Role reviews every release
SAP, SAP Cloud ERP and SAP Cloud Identity Services are trademarks of SAP SE. Microsoft Entra ID is a trademark of Microsoft. Screens shown are illustrations.
At Mawkish, the Eskdale Baseline is how we keep SAP Security, Roles & Authorisations work checked, owned and answered for, whoever does the build.