In typical SmartChange setups, RFC-based technical communication is configured with a technical SAP user of type Service (dialog-capable), e.g., ZRTC4_TM_ADM. This can raise the question why a System user is not used instead.

Key point: Security is primarily determined by the authorization design (roles/authorization objects), not by the user type alone. User type mainly influences operational/logon characteristics and typical usage patterns.

• Commonly used for technical system-to-system communication and background processing.

• Not intended for interactive logon (in many landscapes it is technically prevented).

• Also used for technical/service scenarios, but remains dialog-capable.

• Often chosen when a technical account must behave like a “regular” user from an execution perspective, without implying broad authorizations.

The decision is typically driven by operational robustness and functional completeness across diverse customer landscapes:

1. Maximum functional coverage

• Some TM-related actions and checks may require the technical account to support execution patterns that are more consistently covered with a dialog-capable user across different SAP releases, security settings, and customer hardening baselines.

2. Supportability and troubleshooting

• In real operations, teams sometimes need to verify behavior interactively (e.g., reproducing an authorization error, validating a target-side check, reviewing runtime behavior). A Service user keeps that option available; a System user often does not.

3. Consistency across customer security policies

• Many organizations treat “System” users differently via internal policies (e.g., restricted logon methods, special password handling, automatic lock/validity rules). Using a Service user can reduce the risk of customer-specific policy side effects that break an otherwise working RFC setup.

4. Clear separation between “technical execution” and “user-based execution”

• In typical SmartChange configurations, you may see separate RFC destinations per target system: one using stored technical credentials and another without stored credentials for user-based execution. This supports a design where the technical user stays narrowly scoped while certain actions can be executed with user context when required.

• Keep authorizations minimal: Assign only the SmartChange-required roles/authorizations to the technical RFC user—avoid adding convenience permissions.

• Choose the least required RFC role level per target system: Use the lowest role level that satisfies the required functions.

• Credential hygiene: Manage the password/secret centrally and rotate it according to your standard.

• Restrict where appropriate: Limit the technical user’s usage to the intended clients/processes to avoid unintended execution paths.

In many environments, RFC communication will still work after switching to “System”—but it can reduce supportability (no interactive logon) and may trigger customer-specific policy restrictions that don’t appear in basic connectivity tests. If a change is required, validate it end-to-end (including scheduling/import flows and any user-based execution paths) and align the deviation with REALTECH.