SM36 — SM36 Background Job Definition
SM36 defines and schedules a background job: its name, priority class, start condition (immediate, date/time, after another job, after an event), and one or more steps pointing to an ABAP program with a variant or an external command. Saving SM36 only creates the job in Scheduled status. It does not run until released and until a background work process picks it up.
SM36 is the Basis transaction used to create background job definitions, covering start conditions, job steps, and print parameters. This page covers the release/run distinction that causes most confusion, the tables the job writes to, and the diagnostic order for jobs that never start, fail immediately, or stop being periodic.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,070 words
Purpose
SM36 creates a background job definition: a job name, a priority class (A, B or C, which affects which work processes can pick it up), a start condition, one or more steps, and optional spool settings for the output. The single structural fact behind most confusion is that saving a job in SM36 only puts it into Scheduled status. The job is a record, not a running process. It becomes Released, then waits for its start condition to be true and a free background work process, then moves to Active, then Finished or Cancelled. A job sitting in Scheduled forever, or Released but never Active, is normal SM36 behavior for an incomplete setup, not a system fault.
When it is used
SM36 is used whenever a recurring or one-off background process needs to be set up: nightly reporting, batch interface programs, IDoc reprocessing, archiving runs, or any ABAP report too long or too resource-heavy to run online. Functional consultants ask for a job when a report needs to run unattended or on a schedule; Basis or an authorized functional key user actually creates it in SM36. SM37 is reached for afterward to monitor whether the job ran and to read its log. On S/4HANA, Fiori job monitoring apps are sometimes used for oversight, but the definition itself is still done in SM36 in most landscapes.
How to use it in practice
- Enter a job name and select a job class (A for highest priority, C for lowest)
- Define the start condition: immediate, specific date/time, after another job completes, after an event is raised, or tied to an operation mode
- Add one or more steps, each pointing to an ABAP program with a variant, or an external command, or an external program on the application server
- Set print and spool parameters for the step output if the job produces a list
- Save the job, then release it if creation and release are separate steps in the authorization setup
- Confirm status in SM37 by job name and date range
Key data objects
- TBTCO - job header: job name, job count, status (Scheduled, Released, Ready, Active, Finished, Cancelled), scheduled start date and time, user under whom it runs
- TBTCP - job step detail: program name, variant, step number, print parameters, linked to TBTCO by job name and job count
- TBTCS - control table used for periodic job chaining, holding the periodicity settings that generate the next occurrence
How to prove it in the data
In SE16 on TBTCO, filter by job name and date range and read the STATUS field: P for Scheduled, R for Released, Y for Ready, A for Active, F for Finished, X for Cancelled. Compare SDLSTRTDT/SDLSTRTTM (planned start) against STRTDATE/STRTTIME (actual start) to see how long the job waited. Join to TBTCP on job name and job count to see which step it stopped on and which variant was used.
ECC vs S/4HANA
The job definition model, including the Scheduled/Released/Active/Finished lifecycle and the underlying TBTCO/TBTCP structure, is unchanged on S/4HANA. Fiori apps exist for monitoring and analyzing background jobs across a landscape, which some teams use instead of SM37 for oversight, but SM36 remains the transaction used to actually define a job's steps and start condition. There is no functional replacement for SM36 itself.
Common pitfalls and how to diagnose them
- Job never released - status stuck at P (Scheduled) in TBTCO. The job was saved but nobody released it, or the releasing user lacked authorization for the job class chosen. Check STATUS before assuming a scheduling engine problem.
- Start condition never satisfied - job sits at R (Released) indefinitely. Common with 'after job' where the predecessor job aborted or was deleted, or 'after event' where nothing raises that event. Check the predecessor job's own status and check whether the event is actually triggered anywhere in the system.
- No free background work process - job reaches Y (Ready) but never goes Active. Check SM50 or SM66 for the number and state of BTC work processes on the relevant instance, and check the operation mode in effect; too few BTC processes or all of them occupied by long-running jobs blocks new jobs indefinitely.
- Step fails on start - variant deleted, locked by another user, or containing a value now invalid (a date range that no longer applies, a company code that got locked). The job goes straight to Cancelled with a short runtime; check the job log via SM37 and the variant contents, not the job definition itself.
- Mid-run authorization failure - the job runs under a fixed user whose password expired, role was pulled, or account was locked after the job was scheduled. The job starts, runs partway, and aborts with an authorization dump; the fix is not to reschedule but to correct the run-as user's authorizations or account status.
- Periodicity silently stopped - a periodic job aborts once, and depending on configuration the successor occurrence is never generated because the chain in TBTCS depends on the current occurrence finishing normally. Confirm the next occurrence actually exists before assuming periodicity is broken at the definition level.
Whose problem this is
Background job infrastructure, work process availability, and operation modes are Basis territory. The choice of program, variant, and business schedule is functional. A clean handover states the job name, program and variant, the exact start condition intended, the run-as user, and what a successful job log looks like, so Basis is not left guessing whether a Cancelled status is an infrastructure problem or a bad variant.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/sm36ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.