SU10 — SU10 Mass User Maintenance

SU10 is the mass user maintenance transaction. It lets an administrator select a list of users - manually, by upload, or by selection criteria such as role, profile, user group, or company - and apply one change to all of them in a single run: address data, logon data, roles, profiles, groups, parameters, or validity dates. The structural fact that explains most confusion: SU10 does not maintain a separate object. It drives the same tab-by-tab maintenance dialogs as SU01, one user at a time internally, but only the tab and the specific field or line marked with the change indicator is written back on save. A value typed into a field without the checkbox ticked is displayed but never persisted, which produces the common complaint that a mass change ran cleanly with no errors and changed nothing.

SU10 is reached for whenever a change needs to apply to more than a handful of users: mass onboarding after an acquisition, org restructuring, annual role recertification cleanup, mass lock during an audit finding, or removing a decommissioned role from every user who still holds it. For one or two users, SU01 is faster and safer since it shows the full picture for that user rather than a batch view. For role content itself - what a role actually grants - the tool is PFCG, not SU10; SU10 only assigns or removes the role, it does not shape what is inside it. On S/4HANA, identity lifecycle Fiori apps may sit on top for workflow-driven provisioning, but for a direct, no-workflow bulk change, SU10 is still the tool an administrator opens first.

The sequence matters more than any single screen; skipping the review step is where most unintended changes originate.

The save writes into the same master tables SU01 would, per user, for every field flagged as changed.

To confirm a mass role change actually landed, query AGR_USERS filtered on the role name and the validity date range used in SU10, and compare the returned user list against the intended selection list from that run. To confirm a lock or logon change, check USR02 on the lock flag and validity fields for the same user set, timestamped close to the change. To trace who ran the change and when, check the user master change documents (CDHDR/CDPOS for the user object) since SU10 itself keeps no separate change log of its own.

SU10 and the tables it writes to are unchanged on S/4HANA; the same tab-driven mass maintenance logic applies. Identity and access management Fiori apps exist for workflow-driven provisioning and approval chains, but they operate on top of the same user master tables rather than replacing them. For a direct bulk change with no approval workflow requirement, SU10 remains the immediate tool in both ECC and S/4HANA.

Failures fall into a small number of repeatable categories; work through them in this order before assuming a bug.

This is a security/user administration problem, not ABAP or Basis, unless the transaction is inaccessible or a large batch is timing out for performance reasons. A good handover includes the exact selection criteria used, the tab and fields changed with the change indicators applied, the execution log, and a comparison of the intended target list against the users actually affected.

SU01 is the single-user counterpart whose screens SU10 drives in bulk, and is the reference point for understanding what each tab actually writes. PFCG defines the role content being mass-assigned or removed, so its authorization scope should be understood before a bulk assignment goes out. SUIM is the tool to verify, before and after a mass change, exactly which users hold a given role, profile, or authorization. SM20 provides the security audit log used to trace who ran a mass change and when, filling the gap left by SU10 having no change log of its own.