SAP User Types: Dialog, System, Communication, Service and Reference

User type is a security control in the ABAP user master. Dialog accounts represent individual users and are subject to normal interactive logon/password rules. System users are non-interactive and suitable for background/internal technical processing where credentials may be long-lived according to policy. Communication users are non-dialog technical accounts intended for external system communication. Service users can support shared anonymous/public entry scenarios but weaken individual accountability and require strong restrictions. Reference users cannot log on directly and can supplement authorization assignment to other users in supported scenarios.

Use Dialog for human users. Use System/Communication for technical integrations according to whether access is internal/background or external communication and the platform's supported authentication. Avoid Service users unless the scenario explicitly requires shared anonymous access and risk is accepted. Use Reference users for the narrow authorization pattern they were designed for, not as a way to evade role governance. Prefer modern technical-user/OAuth/certificate identities where the interface supports them.

SU01 stores user master/type; PFCG roles define authorizations; RFC destinations or communication scenarios reference technical identities. Password policy/validity behavior varies by user type. Security audit/change documents track administration. S/4HANA/Fiori still uses ABAP users for backend authorization in many deployments, while IAS/IdP handles frontend authentication; the mapped backend identity remains subject to user type/role rules.

An interface runs nightly with a personal Dialog user because it was easy during testing. When the employee leaves and the account is locked, production integration fails. The team replaces it with a governed least-privilege technical communication identity and documents credential rotation/owner. Conversely, an interactive support user should not be converted to System merely to avoid password expiry; that would weaken accountability/control.

User types remain part of S/4HANA ABAP security, while cloud/communication scenarios increasingly use communication users, OAuth clients, certificates or propagated identity. The strategic direction is strong identity governance and least privilege, not elimination of backend user concepts.

Security/IAM owns user type/policy/roles; application/integration owners define purpose; Basis administers technical accounts; audit/compliance reviews shared/service usage and ownership.

SU01 manages user masters; PFCG roles and SU53/STAUTHTRACE topics cover authorizations. SM59/BTP OAuth topics cover how technical identities are used by integrations.

Production verification: Capture the actual backend user, client and system, failing action, authorization object and field values, assigned roles and validity, trace timestamp, and whether execution was dialog, RFC, background, or propagated from Fiori or BTP. Reproduce under the real identity and correct the least-privilege role rather than testing with SAP_ALL.

Operational readiness: For production readiness of SAP User Types: Dialog, System, Communication, Service and Reference, test with a representative least-privilege business user and with the actual technical or propagated identity used by integrations. Record both allowed and denied scenarios so the role design proves separation of duties rather than merely eliminating errors. Any change that broadens access should identify the business owner and authorization-field scope, and the post-change test should use trace evidence rather than relying only on successful screen navigation.

Review checkpoint: Review checkpoint for SAP User Types: Dialog, System, Communication, Service and Reference: validate the design with at least two users whose organizational scope differs, then capture trace evidence for an allowed and denied operation. Confirm role validity dates, generated profile or user comparison state where applicable, and the actual backend identity used by Fiori, RFC or BTP calls. The production runbook should say which team approves broader access, which authorization fields are business-sensitive, and how emergency access is separated from permanent role design. This turns a one-off authorization fix into a repeatable least-privilege control.