S_BTCH_NAM — Authorization for background job step user
S_BTCH_NAM controls whether a user can define a background job step to run under a different user ID than their own (the job step user). It is checked only when the step user differs from the person creating or changing the step, not for jobs a user schedules and runs as themselves.
This page covers S_BTCH_NAM, the authorization object that governs which user IDs someone can assign as the step user of a background job. It focuses on why this check is so often confused with S_BTCH_JOB, how to isolate a failure with SU53 and trace tools, and the security risk that makes teams restrict this object tightly.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 815 words
What it protects
S_BTCH_NAM governs one specific act: assigning a job step to run under a user ID other than the one creating or changing the job. Every background job step executes as some user, and by default that is the person who scheduled it. The moment someone types a different name into the step user field in the job definition, the system checks whether that person is allowed to impersonate that identity for batch purposes. The structural fact that causes most confusion is that this check does not fire for the common case of scheduling a job to run as yourself. It only activates when the step user field is populated with a name different from the caller. Teams that build interface jobs or copy existing job definitions from another user routinely trip this without realizing the field was populated at all.
Fields checked
- BTCUNAME - the name of the user under which the job step is set to execute. The value the system checks is the target step user, not the id of the person maintaining the job. A role holding this field with a wildcard grants the ability to run any job step as any user in the system, which is why security teams almost never assign it broadly.
Where it is checked
- SM36, on the step definition screen, when the 'user' field for a step is changed away from the creator's own ID before saving.
- SM37, when copying an existing job whose steps already carry a step user different from the person doing the copy - the field carries over silently and the check fires on save even though the copier never typed a name.
- Background job creation triggered from custom programs or interface tools that call standard job-creation logic and pass an explicit step user, most often a technical or service ID used for interface processing.
- Job release or execution flows in some scenarios, where the step user is only fixed at that later point rather than at initial definition, depending on how the job was built.
How to trace a failed check
Reproduce the failure first: attempt to save or release the job step with the step user exactly as it was entered, then immediately run SU53. Look for S_BTCH_NAM with field BTCUNAME and note the value shown as 'checked' - that is the step user name the system rejected, and it may not match what the consultant expected because a copied job can carry a stale value. If SU53 is empty or inconclusive, start an authorization trace (ST01 or the newer trace transaction) before the attempt, reproduce, then read the trace for S_BTCH_NAM entries. Hand security three things: the exact step user name the job attempted to run as, the requester's own user ID, and the job name plus client. Do not ask security to 'just give batch access' - that request usually lands on S_BTCH_JOB instead and leaves S_BTCH_NAM untouched, so the failure repeats.
Whose problem this is
This is a security-team decision, not a functional fix, because granting BTCUNAME broadly is a privilege escalation path. A good request names the specific step user ID needed (for example a fixed interface or batch service user), the job or job pattern it applies to, and confirms the requester has no legitimate need to run steps as any other ID.
Common pitfalls
- Confusing S_BTCH_NAM with S_BTCH_JOB - a user can hold full authorization to release, delete, and manage jobs via S_BTCH_JOB and still fail outright when trying to set a different step user, because that is a separate object entirely.
- Assuming a failed check means the job scheduling authorization is broken in general, when in fact everything about the job itself is fine and only the step user assignment is blocked.
- Copying a job via SM37 from another user's job list and not noticing the copied step already carries that user's ID as step user, which then triggers a check the person copying never intended to invoke.
- Security granting BTCUNAME = * to make a persistent ticket go away, which quietly hands the requester the ability to impersonate any user in batch, including highly privileged technical IDs.
- Concluding from a single failed step that the whole job chain is broken, when only one step in a multi-step job specifies an alternate user and the rest run fine under the scheduler's own ID.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-btch-namERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.