SAPFree templatePDF, Excel, Word exportSAP ECC and S/4HANA

SAP Background Job Scheduling Template: Request Form for SM36 Jobs

Most background job problems start with an incomplete request: no step user, no dependency, no plan for failure. This template is a single-page job request form that gives your Basis team what they need to schedule a job in SM36 and watch it in SM37.

Fill in

Live preview
Download:

SAP Background Job Scheduling Template

SAP Background Job Request

Job name: Z_FI_DUNNING_DAILY Requested by: Finance Process Owner Request date: 2026-10-20

Job step

FieldValue
ABAP program or reportF150DUNNING
VariantZDAILY_DUNN
Step userBATCH_FI
Expected runtime10 to 15 minutes

Schedule

FieldValue
Start conditionDate and time
RecurrenceDaily
Start time02:30, system time
Job classC (low)
Target server or groupBatch server group SAP_BATCH

Dependencies

Runs after the daily payment posting job Z_FI_PAYMENT_POST finishes. Needs the interface file in the inbound directory.

Failure handling and monitoring

Alert the finance support mailbox. Rerun once after checking the log in SM37. Escalate to the Basis on-call if the second run fails.

Monitoring: check the job in SM37 by job name and user, and review the job log and spool output when a run is cancelled.

Approvals

Requester / Date
Process owner / Date
Basis administrator / Date

Use the naming standard agreed in your landscape. Step users should be dedicated technical users with only the authorizations the program needs. Verify the program name and variant in your own system before scheduling.

Plain-language job failure triage

Optional: see how batch job logs can be summarized and routed automatically, running inside your own network.

Optional. The tool and every export work without this. No spam.

How to use the template

Fill in the program or report and its variant, then name the step user, the account the job runs under. Choose the start condition and recurrence, and write the dependencies in plain words. A job that must wait for another job or an incoming file should say so explicitly, because the scheduler needs either a predecessor job, an event or a time window. Describe what should happen if the job fails. Export the document to attach to the change ticket, and hand it to Basis for scheduling. The expected runtime helps monitoring spot a job that runs far too long.

  • Always name a dedicated step user
  • State predecessors and files explicitly
  • Give an expected runtime for monitoring

The scheduling method behind it

A background job is a container of one or more steps. A step runs an ABAP program with a variant, an external command or an external program. The job runs under a step user and carries the authorizations of that user. A start condition decides when it begins: a fixed time, after another job, after an event, or on an operation mode switch. Class A is reserved for urgent jobs and has dedicated capacity, so use it sparingly. Standard housekeeping jobs created from the standard jobs function in SM36, covering reports such as RSBTCDEL2, should be scheduled once and not duplicated.

  • Job, step, variant and step user are separate decisions
  • Class A uses reserved capacity
  • Avoid duplicate housekeeping jobs

Reading the sample form

The example schedules a daily finance dunning job at 02:30 under a dedicated batch user, after the payment posting job. Because it depends on another job, the start condition can be set to run after that job, or the time can be set far enough after it to be safe. The dependency note matters more than the time. If the file does not arrive, the job should fail visibly and alert the right team, not run on empty data and report success. The failure handling note tells operations exactly what to do at 3 a.m.

  • Prefer predecessor or event over guessing a time
  • Make failure visible with an alert
  • Name an on-call escalation path

Common mistakes

The classic mistakes are scheduling under a named person's user, which breaks when that person leaves or gets locked, giving the step user full authorizations because it is easier, and using a variant that changes without anyone noticing. Another is running heavy jobs at the same time as month end load. Jobs also pile up when failed runs are never cleaned up, so schedule the reorganization jobs for old job logs and spool. Finally, if a step user can run any program, it is a security risk that auditors will flag.

  • Use technical step users, not people
  • Limit step user authorizations to the task
  • Review variants and job history regularly

Frequently Asked Questions

What is the difference between SM36 and SM37?

SM36 is used to define and schedule a background job, including its steps and start conditions. SM37 is used to monitor jobs after they are scheduled: you can see status, display the job log, check spool output, release, cancel or delete jobs.

What is a step user in an SAP background job?

It is the user account under which a job step runs, and it determines the authorizations that step has. Use a dedicated technical user with only the access the program needs, rather than a personal account or a user with broad authorizations.

What are SAP job classes A, B and C?

They represent job priority. Class A is the highest priority and has reserved background work process capacity, so it suits urgent work. Class B is medium and class C is the default low priority. Use class A sparingly, or ordinary jobs may wait.

How do I stop old job logs from filling the system?

Schedule the standard housekeeping jobs, which you can create from the standard jobs function in SM36. They run reports such as RSBTCDEL2 to delete old job records and related clean-up for spool and batch input logs. Check the retention settings against your policy first.

If you want job failures explained in plain language and routed to the right team, Netray can build an agent over your SAP job logs and monitoring, running privately in your own network.