SAP_ALL vs SAP_NEW: Why Unrestricted Authorizations Are Dangerous

Every SAP auditor has a favorite question, and it's usually some variant of: "Show me everyone with SAP_ALL." There are few faster ways to turn a routine audit into a difficult conversation. This post explains what SAP_ALL and SAP_NEW actually are, why they exist, and how to handle them without derailing your project.

---

What SAP_ALL is

SAP_ALL is a single profile that contains every authorization in the system — all objects, all fields, all values. A user with SAP_ALL can do literally anything: post in any company code, maintain any user, run any program, read any data. The system performs no authorization checks against them at all.

It exists for legitimate reasons. During a fresh installation or a major upgrade, the basis team needs unrestricted access to configure the system before any roles exist. In a true emergency — production is down, the usual admin accounts are locked — it can be the only way back in. These are narrow, time-boxed scenarios, and that's exactly how SAP_ALL should be treated: a fire axe behind glass, not a daily toolkit.

Key takeaway: SAP_ALL disables every authorization check for that user. Legitimate for installation, upgrades, and genuine emergencies — never for day-to-day work, and never for end users.

---

What SAP_NEW is

SAP_NEW is SAP_ALL's lesser-known sibling, and it's actually the more interesting of the two. After an upgrade or support package, SAP delivers new authorization objects and new default values. Users' existing roles don't include these yet, which means things that worked before the upgrade can suddenly fail authorization checks after it.

SAP_NEW collects exactly those new authorizations — the delta introduced by the upgrade. The intended workflow: assign SAP_NEW to key users during the upgrade test phase so they can exercise the new functionality, identify which of the new checks their roles genuinely need, add those to the roles properly in PFCG, and then remove SAP_NEW. It's a scaffolding, not a structure.

The catch is the last step. SAP_NEW has a habit of surviving long past the upgrade — "we'll clean it up after go-live" — and quietly becoming a permanent, unaudited grant of broad authorizations. Auditors know this pattern well, which is why they ask about SAP_NEW almost as eagerly as SAP_ALL.

---

Why both are audit red flags

From an audit perspective, SAP_ALL and SAP_NEW share the same problem: they bypass the role concept entirely. Every control you've built — job-based roles, SoD splits, org-level scoping — simply doesn't apply to these users. And because they're assigned as profiles (in SU01's Profiles tab) rather than through roles, they don't even show up in a PFCG role review. Someone has to look specifically.

The questions to have answers for: Who currently holds SAP_ALL or SAP_NEW? Why does each of them need it? When was it granted, by whom, and when does it expire? "It's always been like that" is not an answer auditors accept.

---

Making the review stick

A one-time cleanup feels good, but access drifts. People change jobs, projects end, consultants leave — and the SAP_ALL you removed in March has a way of reappearing by September, granted "temporarily" by someone under deadline pressure. The fix is a recurring review: quarterly, pull the list of SAP_ALL and SAP_NEW holders and send it to the security lead for sign-off. Anyone who can't justify their entry loses it.

Pair that with alerting if your tooling supports it. GRC can flag new assignments of critical profiles the moment they're made; even a simple scheduled job emailing the list beats discovering the problem during the audit. The goal isn't to make SAP_ALL impossible to grant — emergencies are real — but to make every grant a conscious, recorded decision with an expiry date attached.

---

The practical handling

First, inventory. Run a report (RSUSR003 in older releases, or the user information system) listing every user with SAP_ALL or SAP_NEW. You'll often find surprises — service accounts nobody remembers, ex-consultants, test users in production.

Second, justify or remove. For each one, either document a genuine business reason with an expiry date, or remove it. Emergency accounts should have their passwords sealed (the classic "firecall" envelope procedure) rather than sitting active. For SAP_NEW specifically, check whether the upgrade it was granted for is long finished — if the roles were properly updated months ago, the scaffolding should have come down with them.

Third, prevent recurrence. Make SAP_ALL/SAP_NEW assignment a controlled process: request, approval, time limit, automatic review. In GRC environments, flag them as critical risks so any new assignment triggers a workflow instead of slipping through quietly.

Handled this way, SAP_ALL and SAP_NEW go from audit nightmare to non-issue. They're tools with a purpose — the discipline is in making sure the purpose is real, documented, and temporary.

Read more →

Segregation of Duties (SoD) in SAP: Toxic Combinations and GRC

Segregation of duties is the idea that no single person should control a process end to end. The person who creates a vendor shouldn't also approve payments to that vendor. The person who counts the inventory shouldn't be the one adjusting the counts. It's common sense — and in SAP, it's a formal discipline with its own tooling, because "common sense" doesn't scale to ten thousand users.

---

What makes a combination "toxic"

A toxic combination is a pair (or trio) of permissions that are each innocent on their own but dangerous together. The textbook example: create/change vendor master (XK01/XK02) plus post invoice (MIRO/FB60) plus execute payment run (F110). One person with all three can invent a fake vendor, post a fake invoice, and pay themselves — with the system happily recording every step as "authorized."

Other classics: create purchase order + goods receipt + invoice verification (the full procure-to-pay chain in one pair of hands), or maintain exchange rates + post journal entries. The pattern is always the same — the ability to both create the thing and approve or settle it.

Note that toxicity lives at the role and user level, not the transaction level. MIRO isn't dangerous. XK01 isn't dangerous. A user holding both is.

Key takeaway: SoD isn't about blocking transactions — it's about making sure no one user holds the complete chain of a sensitive process. Design it out at role level; don't try to police it user by user.

---

Designing SoD out of your roles

The cheapest place to handle SoD is during role design, before anyone is assigned anything. Map your end-to-end processes — procure-to-pay, order-to-cash, hire-to-retire — and mark the steps that must be split. Then make sure no single role spans a split.

This is where the PFCG role types earn their keep. Build single roles per process step (vendor maintenance, invoice posting, payment execution as three separate roles), and only combine them in composite roles where the business genuinely requires it — with sign-off. When the auditor asks "who can do the whole P2P chain?", the answer should be a short, documented list, not a shrug.

Derived roles help too: the same step-role derived per company code keeps the SoD structure intact while scoping the data. The split is by function; the derivation is by organization. Don't confuse the two.

---

GRC Access Control: the systematic approach

For larger landscapes, spreadsheets don't cut it, and that's where SAP GRC Access Control comes in. Its core is Access Risk Analysis: you load SAP's (or your own) ruleset of toxic combinations, and it scans every user and role, reporting exactly who holds what risk and at which level (critical, high, medium).

Two concepts do most of the heavy lifting. Mitigating controls are documented compensating measures for risks you accept — "yes, the plant manager holds both, and here's the monthly review that catches misuse." Emergency Access Management (the old "firefighter") gives selected users temporary elevated access for incidents, with every action logged for review. Both exist because the real world sometimes needs exceptions — the point is that exceptions are visible and approved, not invisible.

GRC also watches the provisioning side: when a new role assignment would create a toxic combination, it can block or flag it before it's granted. Prevention beats detection every time.

One more thing worth doing early: run risk analysis on your roles, not just your users. A role that internally contains a toxic combination is a landmine — every user who gets that role inherits the risk silently. Cleaning the roles first means every subsequent user assignment starts from a safe baseline, and your user-level reports stay mercifully short.

---

The conversation to have with the business

Here's the uncomfortable truth about SoD: the security team can't define it alone. Only the business knows which combinations are actually dangerous in their processes. A toxic combination in a manufacturing company's P2P flow might be irrelevant in a services company — and vice versa.

So the practical move is a workshop, not a tool purchase. Walk through each core process with the process owners, agree on where the splits must be, document the decisions, and then encode them in roles and GRC rules. The tool enforces the policy; the business has to write the policy first.

Done right, SoD is invisible — users get the access their job needs, risks are designed out, and the audit is a non-event. Done wrong, it's either a straitjacket that blocks legitimate work or a fiction nobody enforces. Aim for the first one.

Read more →

ACTVT Authorization Activities in SAP Explained (01, 02, 03)

Open almost any authorization object in PFCG and you'll find a field called ACTVT. It's short for "activity," and it's the field that answers the question every manager asks: "Can they just look, or can they actually change things?" Understanding ACTVT is understanding how SAP separates display access from real power.

---

What ACTVT is

ACTVT is a standard field that appears in a huge number of authorization objects — from financial documents (F_BKPF_BUK) to material masters (M_MATE_WRK) to datasets (S_DATASET). Instead of each object inventing its own way to say "create" or "display," they all share this one field with a standardized set of values.

The values you'll meet constantly are:

01 — Create. The user can create new objects: new documents, new master records, new entries.

02 — Change. The user can modify existing objects.

03 — Display. The user can look but not touch. This is the workhorse of read-only access.

06 — Delete. The user can delete objects — usually the most restricted of the set.

There are others (16 for Execute, 70 for Administer, and object-specific values into the 70s and 80s), but 01/02/03/06 cover the vast majority of day-to-day role design. When someone says "give them display access," they mean ACTVT = 03.

Key takeaway: ACTVT is SAP's universal vocabulary for what a user may do: 01 create, 02 change, 03 display, 06 delete. Display-only (03) is the safest access you can grant — and the one auditors love to see.

---

How it works in practice

Take the classic example: object F_BKPF_BUK (accounting document, company code level). A role for an AP clerk who posts invoices needs ACTVT values 01 and 02 for the relevant company codes — create and change. A role for the financial controller who only reviews needs ACTVT = 03 for the same company codes. Same object, same company code, completely different power — all controlled by one field.

This is why the traffic-light maintenance in PFCG matters so much. When you leave ACTVT at * (all values) because you were in a hurry, you've given that role create, change, and delete across the board. The five minutes you saved will cost someone a very uncomfortable audit meeting.

---

Display-only roles: the pattern to reuse

One of the most useful patterns in SAP security is the display-only role: a role where every authorization object carries ACTVT = 03 and nothing else. Auditors get one. Managers who need visibility but shouldn't post get one. Support teams diagnosing production issues get one.

Building these is straightforward — copy a working role, change all ACTVT fields to 03, regenerate — but there's a subtlety worth knowing. Some transactions need more than 03 to even open in display mode, because the program checks 02 at some internal step. When a "display" user hits an authorization error on a display transaction, check SU53: if the failed check is ACTVT with a required value of 02 on an object you set to 03, you've found one of these cases. The fix is a targeted exception, documented, not a blanket upgrade to 02.

---

Maintaining ACTVT in PFCG without the guesswork

When you maintain authorization data in PFCG, ACTVT fields show up with SAP's proposed default values — and the temptation is to accept them all and move on. Don't. The defaults are generous by design; SAP would rather propose too much than break a transaction. Go field by field and ask: does this job create, change, display, or delete? Set exactly that.

One practical tip: use the "Display" maintenance mode mentally before you start. Decide up front which parts of the role are display-only, and set those ACTVT fields to 03 first. Then handle the create/change/delete fields deliberately. Roles built this way — display by default, power by exception — pass audits far more comfortably than roles where everything was left at full authorization "temporarily."

---

Where ACTVT shows up beyond PFCG

You'll meet ACTVT in SU53 output constantly — "required 02, user has 03" is probably the single most common authorization failure pattern in existence. It also appears in GRC risk analysis, where rules flag combinations like "create vendor (01) + approve payment (02)" as segregation-of-duties risks.

And in S/4HANA Cloud's business roles, the read/write restriction model is essentially ACTVT wearing different clothes: "read access" maps to the 03 world, "write access" to the 01/02 world. The vocabulary changed; the concept didn't.

Learn the four core values cold — 01, 02, 03, 06 — and a surprising amount of SAP authorization troubleshooting starts to read like plain language.

Read more →

Maintain Business Roles in S/4HANA Cloud: Authorizations Without PFCG

If you learned SAP security on ECC or S/4HANA on-premise, your muscle memory says PFCG. In S/4HANA Cloud (public edition), PFCG doesn't exist for you. Neither does SU01. Instead, authorizations are built in a Fiori app called Maintain Business Roles — and while the concepts carry over, the mechanics are different enough to trip up experienced consultants.

---

Why PFCG had to go

PFCG is powerful, but it's also a GUI transaction built for an era of green screens and basis administrators. S/4HANA Cloud is API-driven, multi-tenant, and updated continuously — SAP needed an authorization model that fits Fiori apps, business catalogs, and a clean core where customers can't touch the underlying roles SAP ships.

The replacement splits the old world into cleaner pieces. Instead of SU01 you have the Maintain Business Users app. Instead of PFCG you have Maintain Business Roles. And instead of transaction codes in a role menu, you work with business catalogs — SAP-delivered bundles of Fiori apps grouped by business function, like "Accounts Payable — Processing" or "Manage Bank Accounts."

Key takeaway: In S/4HANA Cloud you don't build menus from transactions. You assemble SAP-delivered business catalogs into business roles, then fine-tune what each role can actually do with restrictions.

---

Anatomy of a business role

Open Maintain Business Roles and create a new role. The first thing you'll notice is there's no menu tab. Instead, you add business catalogs on the "Business Catalogs" tab. Each catalog brings a set of Fiori apps (tiles) that appear on the user's launchpad. SAP ships hundreds of these catalogs, and you generally don't modify them — you pick the ones matching the job.

The real authorization work happens under Restrictions. For each catalog, you set two things: read access and write access, each with an access context. "Unrestricted" means everything. "Restricted" lets you scope it down — by company code, plant, purchasing organization, and so on. This is the cloud equivalent of maintaining org-level fields in PFCG, and it's where most of the design effort goes.

A role for an AP clerk in company 1000 might therefore contain the AP processing catalogs with write access restricted to company code 1000, plus a few display-only catalogs for reporting. The user sees exactly the apps they need, and the data they can touch is fenced off by the restrictions.

---

What carries over from PFCG thinking

The design discipline is identical: build roles around jobs, not people. One role per job function, named clearly. Resist the urge to create a bespoke role per user — the same sprawl that ruins PFCG systems ruins business role catalogs too.

Segregation of duties still applies, arguably more so, because the catalog model makes it tempting to just keep adding catalogs until the user stops complaining. The same toxic combinations (create vendor + pay vendor, for instance) need to be designed out at the role level, not discovered by the auditor.

And testing still matters. S/4HANA Cloud gives you a preview of the role as a specific user would see it — use it. Check the launchpad tiles, try the restricted transactions, confirm the scoping actually fences the data. Finding out in production that "restricted to company 1000" didn't apply to one catalog is an unpleasant surprise.

---

The practical differences to remember

A few things catch PFCG veterans out. First, you can't see or change the authorization objects underneath — SAP abstracts them away behind the catalog and restriction model. That's deliberate; it keeps the core clean across upgrades, but it means less fine-grained control than PFCG's traffic lights.

Second, transports work differently. Business roles move through the cloud's transport lifecycle (export/import via the "Export Customizing Transports" or transport management in Central Business Configuration), not TMS. Plan your landscape strategy accordingly.

Third, SAP delivers new catalogs with every release. After each upgrade, review what's new — there's often a catalog that replaces a workaround you built, or a restriction option that finally covers a gap. The continuous-innovation model only pays off if someone actually looks at what's new.

Maintain Business Roles is simpler than PFCG on the surface, but don't mistake simpler tooling for simpler decisions. The hard part was never the transaction — it's deciding what each job should be allowed to do, and having the discipline to say no to everything else.

Read more →

Authorization Troubleshooting in SAP: SU53, S_TCODE and Common Checks

"I don't have authorization for this." It's the most common ticket in SAP security, and the fix is usually five minutes — if you know where to look. The single most useful transaction for these tickets is SU53, and understanding what it shows (and what it doesn't) will save you hours of guessing.

---

SU53: the last failed check

Here's the workflow. A user tries to do something and gets the dreaded "No authorization" message. Tell them — immediately, before they do anything else — to run transaction SU53 in the same session. SU53 displays the last failed authorization check for that user: the authorization object, the field names, the values the system required, and the values the user actually had.

The timing matters. SU53 shows only the most recent failure, and it resets with every new check. If the user runs three more transactions before calling you, the evidence is gone. Train your helpdesk to ask for SU53 output as the first step, not the last.

Reading the output is straightforward once you've seen it a few times. You'll see something like: object F_BKPF_BUK, field BUKRS, required value 2000, user's values 1000. Translation: the user tried to post in company code 2000 but their role only allows 1000. The fix is a role change, not a system problem.

Key takeaway: SU53 is a snapshot of one failed check, taken at the moment of failure. Get the user to run it immediately — it's the fastest path from "access denied" to the actual missing value.

---

S_TCODE: the gatekeeper at the door

Before SAP checks any fancy authorization object, it checks one simple thing: is this user allowed to start this transaction at all? That's the job of S_TCODE, and it's evaluated at transaction start, before anything else runs.

This is why a huge number of SU53 outputs show S_TCODE as the failed object. The user was never even let through the door. It usually means the transaction simply isn't in their role menu — someone asked for "access to MIRO" but the role only contains FB60, or the Fiori catalog doesn't include the app.

The fix for a failed S_TCODE check is almost always in PFCG: add the transaction to the role menu, maintain the authorization data, regenerate, and run the user comparison. Don't try to fix it by hand-adding S_TCODE values somewhere — the menu-driven approach keeps everything consistent.

---

When SU53 isn't enough: the trace

Sometimes the failure doesn't reproduce cleanly, or the user needs a whole sequence of checks analyzed rather than one snapshot. That's when you reach for ST01, the system trace. Turn on the authorization check trace, have the user repeat the failing action, then turn the trace off and analyze. You get every check the system performed — passes and failures — with the exact values compared.

ST01 is heavier than SU53 and you shouldn't leave it running, but for the stubborn cases — background jobs failing at 2 AM, Fiori apps throwing vague errors — it's the definitive tool. There's also SU24, which maintains the default check indicators for transactions (whether a transaction checks a given object at all, and with what default values). If a transaction should check an object but doesn't, SU24 is where that behavior is controlled.

---

Common SU53 patterns and what they mean

After you've read a few dozen SU53 outputs, the same patterns keep appearing. Missing S_TCODE means the transaction isn't in any of the user's roles — a menu gap, fixed in PFCG. Right object, wrong org value (required company 2000, user has 1000) means the role is scoped too narrowly for what the user actually does — either extend the role or create a derived one for the new org unit.

Right object, right org, wrong activity — required 02, user has 03 — is the trickiest, because it's a judgment call. Does this user genuinely need change access, or were they only ever supposed to display? Don't just bump the value; check with the role owner. And if SU53 shows an object you've never seen before with a cryptic name, that's often a custom authorization object (starting with Z or Y) from in-house development — the fix usually involves the development team, not just the role.

---

The troubleshooting habit

A clean authorization ticket follows the same pattern every time: reproduce the error, capture SU53 immediately, read the failed object and the missing value, decide whether it's a missing transaction (S_TCODE → menu gap), a missing org value (role too narrow), or a genuinely new requirement (role needs extending). Fix it in PFCG, regenerate, compare users, and have the user retest.

What you should not do is the thing everyone is tempted to do: slap SAP_ALL on the user "just to see if it works." It always works, it proves nothing, and if you forget to remove it — which happens more often than anyone admits — you've just handed someone the keys to the kingdom. SU53 first, always.

Read more →

PFCG Role Maintenance, Authorizations and Profiles in SAP Explained

If SU01 is the HR file, PFCG is the job description. It's where you define what a user is allowed to do, and it's the transaction SAP security consultants spend most of their lives in. Roles are the single most important concept in SAP authorization management, so it's worth understanding exactly how they're built.

---

The hierarchy: user → role → profile → authorization

Authorizations in SAP work in layers, and mixing them up causes endless confusion. At the top sits the user (SU01). Users don't hold authorizations directly — they hold roles. A role is a bundle of permissions for one job function: "Accounts Payable Clerk," "Warehouse Supervisor," that sort of thing.

Inside a role, the menu (the transactions and apps you've added) generates authorization data. When you generate the role, the system compiles that data into a profile — a technical container the kernel actually checks at runtime. And inside the profile are individual authorizations: instances of authorization objects with specific field values, like "company code 1000, activity 03 (display)" for object F_BKPF_BUK.

So the chain is: user gets roles, roles generate profiles, profiles contain authorizations, authorizations are checked against objects. You maintain roles in PFCG; everything below that is generated.

Key takeaway: Never assign authorizations directly to users. Always go through roles — it's the only structure that stays maintainable and auditable as the system grows.

---

Building a role, step by step

Create the role in PFCG and give it a sensible name — most companies use a naming convention with a prefix per module or company code, because a thousand roles named "TEST_ROLE_1" through "TEST_ROLE_999" is a special kind of pain.

On the Menu tab, add the transactions, reports, and (in S/4HANA) Fiori apps the job needs. This is deliberately the first step: the menu drives which authorization objects the system proposes on the next tab, so a complete menu saves you manual work later.

On the Authorizations tab, click the "Change authorization data" button. PFCG proposes the authorization objects for everything in your menu. Now comes the real work: maintaining the field values. Each object shows a traffic light. Red means unmaintained — the role won't generate until you fix these. Yellow means you changed SAP's proposed standard values. Green means maintained and ready. Work through the reds, setting organizational levels (company code, plant, purchasing org) and activities (create, change, display) to exactly what the job needs — no more.

Then click Generate (the red-and-white icon). This compiles the profile. Finally, go to the User tab, assign the users, and run a user comparison so the new profile lands in their user masters.

---

Single, composite, and derived roles

A single role is the basic building block: one menu, one set of authorizations, one generated profile. Most roles should be single roles.

A composite role is a container that bundles several single roles together. You'd use one for a job that genuinely spans functions — say a plant manager who needs the production supervisor role plus the maintenance planner role. Assigning the composite to the user is cleaner than assigning five singles, and when the job changes you update the composite once.

Derived roles solve a different problem: the same job in different organizational units. You build a parent role for "AP Clerk" with company code left open, then derive children for company code 1000, 2000, 3000. The menu and most authorizations inherit from the parent; only the org-level fields differ. Change the parent's menu and the change flows down — much better than maintaining three near-identical roles by hand.

---

What usually goes wrong

The number one sin is the over-authorized role: someone couldn't be bothered to maintain the red traffic lights properly, so they set everything to * (full authorization) to make the errors go away. The role works, the ticket closes, and six months later the auditor asks why every AP clerk can post in every company code. Maintain the values properly the first time — it's slower, but it's the entire point of the exercise.

The second is role sprawl: hundreds of one-off roles created for individual users instead of a clean set of job-based roles. If your role count is approaching your user count, the design has failed. Step back, define the actual jobs in the business, and rebuild.

PFCG rewards patience. A well-designed role catalog — single roles per job, composites for combined jobs, derived roles for org splits — is the difference between security you can manage and security you merely hope is working.

Read more →

SAP User Administration: SU01 and User Types Explained

Every SAP user — the finance clerk posting invoices, the background job closing the month, the RFC connection pulling orders from a webshop — starts life in the same place: transaction SU01. It's the user master record, and getting it wrong is one of the quietest ways to create a security mess. This post walks through what SU01 actually maintains and the five user types, because picking the wrong type is a mistake that shows up in audits again and again.

---

What SU01 maintains

Think of SU01 as the HR file for a user ID. It doesn't hold authorizations directly — that's PFCG's job — but it holds everything the system needs to know about who is logging on.

The record is split across tabs. The Address tab is self-explanatory. Logon data is where the important stuff lives: the user type, the initial password, and the validity period. Defaults holds the logon language, date format, and decimal notation. Parameters stores SAP GUI parameter IDs (like a default company code). And the Roles and Profiles tabs are where you attach what the user is allowed to do.

Two related transactions are worth knowing. SU01D displays a user without any change authorization — handy when you need to look but must not touch. SU10 does the same job as SU01 but for many users at once, which you'll appreciate the first time someone asks you to lock 400 accounts before a go-live.

---

The five user types

This is the part that matters most. SAP has five user types, and each one changes how the system treats the account.

Dialog (A) is the normal, everyday user. A person sits at a screen, types a password, and works interactively. Most of your user base is type A. Dialog users can change their own password, and they're subject to the usual password rules.

System (B) is for background processing and internal RFC calls. A system user cannot log on through SAP GUI at all — the dialog logon is technically blocked. This is exactly what you want for the account that runs your nightly batch jobs or the technical user behind an interface. If that account's password ever leaks, nobody can sit down at a screen and use it interactively.

Communication (C) covers external RFC and CPIC calls — think third-party tools or web services calling into SAP. Like system users, communication users can't do a dialog logon. The password rules are also relaxed for them, since a human never types the password; it's stored in a destination or connector configuration.

Service (D) is the odd one. It's a dialog user shared by many anonymous people — the classic example is a training account or a kiosk in a warehouse where whoever walks up uses the same ID. Service users all share one initial password that never expires, which is precisely why auditors hate finding them in production with real authorizations.

Reference (L) can't log on at all, ever. It exists purely as a template: you attach roles to a reference user, then point real users at it so they inherit those roles automatically. It's a neat way to give an entire department the same baseline authorizations without assigning roles one by one.

Key takeaway: Dialog (A) is for people at screens. System (B) and Communication (C) are for technical accounts that must never log on interactively. Service (D) is shared and risky. Reference (L) is a template, not a real user.

---

Creating a dialog user: the practical steps

In SU01, enter a new user ID and choose Create. On the Address tab, fill in at least the last name — the system won't save without it. On the Logon data tab, set the user type to Dialog, assign an initial password, and — this is the step people skip — set a validity period. A user with no end date lives forever, including after the employee leaves.

Switch to the Roles tab and add the PFCG roles the user needs. Save. The user still can't do anything useful until a user comparison runs (transaction PFUD), which writes the role's generated profile into the user master. In most systems this runs as a scheduled background job, so new authorizations can take a while to kick in — a common source of "I just gave them the role, why can't they post?" tickets.

---

Common mistakes to avoid

The classic error is creating a dialog user for a background job "because it was easier to test with." That account can now log on interactively, bypassing every control you thought you had. Batch and interface accounts should always be type B or C.

Another is leaving the validity period blank. Tie it to the employment contract or the project end date wherever you can. And never, ever hand out SAP_ALL or SAP_NEW through SU01's Profiles tab directly — profiles assigned there bypass role maintenance entirely, which means nobody reviewing roles in PFCG will see them.

Get SU01 right and the rest of SAP security — roles, authorizations, audits — sits on a solid foundation. Get it wrong, and you're building on sand.

Read more →