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.