Symphony · Background Job Management

The scheduler caught the failureWho governs the recovery?

Symphony Background Job Management schedules and monitors SAP and enterprise jobs, then governs what every scheduler leaves manual: the triage, the restart decision, the approval, and the audit evidence.

A blind retry on a failed payment run can pay vendors twice. Symphony recovers failed jobs autonomously with isAI, approved in Microsoft Teams through Maestro, and logged as the work happens.

Watch Recovery in Under Two Minutes

Built for SAP ECC and S/4HANA operations

Map the recovery gaps on SAP jobs

Pick the failures that hit operations most, and BCS maps the governed recovery path.

Work email *

Company *

Job title *

Which failures matter most?

Something went wrong. Please try again or email info@businesscoresolutions.com.

BCS uses these details only to map the recovery gaps and respond. See the privacy policy.

Thanks, the request is in

BCS will follow up on the selected failures. To talk sooner, book a 30-minute walkthrough.

Download the SAP Job Recovery Runbook (PDF)

The 2:14 AM problem

A retry is not a recovery

At 2:14 AM the automatic payment run cancels on a duplicate key. No operator is on shift, and a blind SM37 repeat would pay vendors already dispatched a second time. Detection was never the problem: the triage, the decision, the approval, and the evidence that follow are where the cost accrues.

Recovery delay

Failed jobs wait on owners, approvals, and manual follow-up. Off-hours, recovery can begin only when the next shift arrives, and every minute extends the outage.

Drives MTTR

Audit and control exposure

Evidence gets reconstructed after the incident instead of captured during it. A thin recovery trail is a control finding waiting to happen: who approved the restart, and when?

Compliance risk

Operating risk

Close windows, cutovers, and maintenance events leave little room for manual recovery, and one unhandled failure can cascade through an interdependent chain.

Go-live and close risk

SAP job failure runbooks

Which SAP job failures does Symphony recover?

Each runbook is a real failure SAP operations teams hit, from a cancelled payment run to a stalled job chain. Step through one and toggle between manual recovery today and Symphony BGM, where isAI recommends the safe action, Maestro approves it in Microsoft Teams, and the evidence is captured live.

Symphony · Recovery ConsoleLive

Runbook #1: Payment run cancels overnight (F110_PAYMENT_RUN_0200 (SAPF110S))

The automatic payment run (SAPF110S) cancels at 02:14 on a duplicate key, and a blind re-schedule risks a double payment.

PRD-ECC SM37 · F110 SEV-1 Owner: AP / Treasury + Basis · SLA: Bank cutoff

Business impact: Vendor payments blocked, and a blind restart risks paying twice before the bank cutoff.

Detect

Adds delay

Auto-detected

Decide

Manual triage

AI recommends

Approve

Approver sign-off

Owner approves

Recover

Human action

Auto-executed

Audit

Manual log

Logged live

# LOG_VIEWER # TRACE_ENABLED

[02:14:01] ALERT: SAPF110S (F110 run) cancelled in client 100.

[02:14 to 06:12] NO ACTION: waiting for on-call personnel.

[06:13:00] TRIAGE: ST22, DBIF_RSQL_SQL_ERROR, duplicate key on REGUH.

[06:25:00] DECISION: an SM37 'repeat' would re-pay, double-payment risk.

[06:35:00] RECOVERY: F110 restarted after-termination by hand; reconciled manually.

[02:14:01] ALERT: SAPF110S (F110) cancelled, REGUH duplicate key.

[02:14:03] DETECT: ST22 dump captured; run state read; dependents mapped.

[02:14:07] RECOMMEND: resume via F110 → After Termination → Draw up again (never re-schedule).

[02:16:40] APPROVE: routed to AP / Treasury, approved.

[02:18:05] RECOVER: run resumed; only unpaid items dispatched; medium created once.

[02:18:30] AUDIT: REGUH/REGUP vs FBL1N reconciled; evidence written to record.

TodayA blind SM37 restart risks a double payment, MTTR runs to hours, reconciled by hand.

With SymphonyResumed safely via F110 after-termination in minutes, one approval, reconciled and logged.

Runbook #2: Job chain stops at a step (FIN_DAILY_CHAIN · step 4 (RFBIBL00))

A nine-step finance chain cancels at step 4, and the remaining steps stall behind it.

PRD-S4HANA SM37 · SM36 SEV-2 Owner: Basis + chain owner · SLA: Downstream 05:00

Business impact: One failed step holds five downstream jobs, and a full-chain rerun reprocesses work already completed.

Detect

Adds delay

Auto-detected

Decide

Manual triage

AI recommends

Approve

Approver sign-off

Owner approves

Recover

Human action

Auto-executed

Audit

Manual log

Logged live

# LOG_VIEWER # TRACE_ENABLED

[02:20:00] ALERT: FIN_DAILY_CHAIN step 4 (RFBIBL00) cancelled.

[02:20 to 06:00] NO ACTION: on-call unsure whether to rerun the whole chain.

[06:05:00] TRIAGE: which steps completed, which are safe to skip, checked by hand.

[06:30:00] RECOVERY: full chain rerun, reprocessing steps 1 to 3 needlessly.

[02:20:00] ALERT: FIN_DAILY_CHAIN step 4 (RFBIBL00) cancelled.

[02:20:03] DETECT: chain state read; steps 1 to 3 complete, 5 to 9 held.

[02:20:07] RECOMMEND: selective restart from step 4 only, not the whole chain.

[02:22:10] APPROVE: routed to the chain owner, approved.

[02:24:00] RECOVER: step 4 restarted; steps 5 to 9 released in sequence.

[02:24:20] AUDIT: chain state, decision, approver and completion logged.

TodayA full-chain rerun reprocesses completed work and burns the downstream window.

With SymphonyRestarted from the failed step only; downstream steps released cleanly in order.

Runbook #3: Job overruns its SLA window (ZSD_AR_INVOICE_EXTRACT_DAILY)

A daily invoice extract runs 210% over baseline and threatens the 06:00 reporting SLA.

PRD-ECC SM37 · SM50 SEV-2 Owner: Reporting owner + Basis · SLA: Reporting SLA 06:00

Business impact: Reporting and dependent SLAs are at risk while the queue stalls behind the overrunning job.

Detect

Adds delay

Auto-detected

Decide

Manual triage

AI recommends

Approve

Approver sign-off

Owner approves

Recover

Human action

Auto-executed

Audit

Manual log

Logged live

# LOG_VIEWER # TRACE_ENABLED

[03:40:00] ALERT: ZSD_AR_INVOICE_EXTRACT_DAILY 210% over baseline.

[03:40 to 05:10] NO ACTION: no one authorised to wait, kill or reroute.

[05:11:00] TRIAGE: SM50/SM66, progressing or hung? SM12 for locks.

[05:25:00] DECISION: extend or kill, debated manually as the SLA nears.

[05:58:00] RECOVERY: killed (SM50) and restarted late; SLA already breached.

[03:40:00] ALERT: runtime breach on ZSD_AR_INVOICE_EXTRACT_DAILY.

[03:40:04] DETECT: SM50/SM66, hung in a lock wait; dependent chain identified.

[03:40:09] RECOMMEND: kill and restart from the supported restart point vs. extend.

[03:41:30] APPROVE: SLA action acknowledged by the reporting owner.

[03:42:10] RECOVER: SM50 cancel-without-core; SM12 locks cleared; restarted; queue rebalanced.

[05:55:00] AUDIT: breach, decision, approver and SLA outcome logged.

TodayEveryone waits because no one is authorised to act, and the SLA quietly slips.

With SymphonySLA held; dependents resume cleanly with no manual queue surgery.

Runbook #4: Jobs stay suspended after patching (Batch set · 84 jobs suspended)

After a patch window, 84 suspended jobs must restart in order, and some do not.

PRD-ECC BTCTRNS1/2 SEV-2 Owner: Window owner · SLA: Patch window

Business impact: A suspended job quietly never comes back, and its missing output surfaces days later.

Detect

Adds delay

Auto-detected

Decide

Manual triage

AI recommends

Approve

Approver sign-off

Owner approves

Recover

Human action

Auto-executed

Audit

Manual log

Logged live

# LOG_VIEWER # TRACE_ENABLED

[01:00:00] WINDOW: BTCTRNS1 suspends 84 released jobs for patching.

[04:30:00] RESTART: BTCTRNS2 run, but the order is ad hoc.

[+2 days] DISCOVERY: a job never resumed; its output is missing.

[+2d] RECOVERY: traced and rerun manually, days late.

[01:00:00] SNAPSHOT: 84 released jobs and dependency order captured; none mid-run.

[04:25:00] DETECT: window closing; system-health check pending.

[04:25:04] RECOMMEND: restart sequence built; do-not-resume jobs flagged.

[04:28:00] APPROVE: system health confirmed by the window owner.

[04:30:00] RECOVER: BTCTRNS2 release; each tier verified before the next.

[04:42:00] AUDIT: SM65 consistency; suspended vs resumed reconciled to zero.

TodayA suspended job quietly never resumes, and nobody notices until its output is missing.

With SymphonyEvery suspended job accounted for, reconciled to zero, in order.

Runbook #5: Scheduled job silently stops (SAP_REORG_SPOOL (RSPO1041))

A daily spool reorg drops off the schedule, and no failure is ever raised because nothing runs.

PRD-ECC SM37 · SM36 SEV-3 Owner: Basis owner · SLA: Daily 02:00 cadence

Business impact: A job that never runs raises no alert, so the gap grows unseen until its downstream effect turns material.

Detect

Adds delay

Auto-detected

Decide

Manual triage

AI recommends

Approve

Approver sign-off

Owner approves

Recover

Human action

Auto-executed

Audit

Manual log

Logged live

# LOG_VIEWER # TRACE_ENABLED

[--:--:--] NO ALERT: SAP_REORG_SPOOL not scheduled; nothing fires.

[+6 days] DISCOVERY: spool table growth noticed by accident.

[+6d 14:00] TRIAGE: SM37 history, was it deleted, unreleased, or failing?

[+6d 15:30] RECOVERY: reinstated and run by hand, catch-up scope unclear.

[02:00:00] WATCH: expected run for SAP_REORG_SPOOL (RSPO1041) is due.

[02:05:00] DETECT: time-since-last-success breach; absence flagged.

[02:05:04] RECOMMEND: re-create the daily job; run RSPO1041 once to catch up.

[08:10:00] APPROVE: catch-up scope confirmed by the Basis owner.

[08:12:00] RECOVER: job rescheduled (SM36); RSPO1041 run; SP12 checked.

[08:12:03] AUDIT: stop time, reinstator and next-run schedule logged.

TodayA job that never runs cannot raise a flag, so the loss stays invisible until it is expensive.

With SymphonyCaught by absence against an expected-job baseline, not by an alert that never comes.

What changes with Symphony BGM

One governed loop, run by isAI and Maestro

BGM keeps the alert and adds the layer every scheduler leaves out. isAI reads the failure, rules out the unsafe action, and recommends the recovery. Maestro routes the approval into Microsoft Teams, then executes only what was approved and records the evidence as the work happens.

Monitor

The job and every dependency, not only the alert

02isAI

Recommend

Classifies the failure and proposes the safe action

03Maestro

Approve

Routes the decision to the owner in Microsoft Teams

04isAI

Recover

Runs the approved action, and only that action

Audit

Failure, decision, approval and outcome logged live

Manual recovery today

With Symphony BGM

Alert raised, then it waits

Job and dependency context captured

Owner searched manually

Owner mapped by policy

Restart decision delayed

isAI recommends the action with context

Approval chased over calls

Maestro routes approval in Microsoft Teams

Ticket updated later

Ticket updated during the flow

Evidence reconstructed after

Audit trail captured live

See it in action

A failed SAP job, recovered and approved in Teams

In this walkthrough a scheduled SAP job fails on a reorganisation error. Symphony detects it, recommends the corrective action, and routes the approval to the owner in Microsoft Teams, then runs the approved step and records the evidence, with no console switching.

Everyday job management

What does BGM run day to day?

Recovery is only part of the picture. BGM also handles the everyday scheduling, monitoring, maintenance, and alerting that background jobs need, across SAP and non-SAP systems, from a single layer.

Scheduling

Run any job on any calendar, and restart a broken chain from the step that failed, not from the top.

Time, event, and dependency-based triggers
Multi-timezone factory and holiday calendars
Selective restart inside job chains, including SAP steps

Monitoring

See every job in one place, and catch a slowdown before it turns into a missed SLA.

One live view of jobs and chains across the estate
Runtime analytics that flag drift early
History and forecasting for audits and capacity planning

Maintenance

Move through a patch window and come out the other side with every job accounted for.

Suspend and release whole job sets in one action
Auto-resume or skip jobs when the window closes
Near-zero-downtime operation during planned maintenance

Alerts

Know the moment a job slips, and send that signal straight to the people and tools that act on it.

Failure alerts at job, chain, and SAP step level
Long-running and missed-run detection
One alert inbox, with email and ITSM routing

Proven in production

Built for SAP operations at enterprise scale

Customer success · utilities enterprise

Global utility enterprise

SAP and non-SAP job orchestration, modernised from a legacy scheduler.

200K+monthly SAP & non-SAP job executions

2 monthsto production go-live

No criticalincidents in hypercare

"Symphony gave us the safety net we needed through our S/4HANA migration: recovery became governed, not improvised."

Faster recovery routing

Alerts become owned recovery paths, lowering MTTR on critical jobs.

Less manual audit prep

Evidence is captured during recovery, not reconstructed before an audit.

Shorter job onboarding

New jobs adopt the governed model without bespoke scripting.

Observed across Symphony Background Job Management deployments.

Runs across the enterprise stack

SAP ECCS/4HANASAP BTPSAP CALMServiceNowMicrosoft TeamsJIRAAzureAWSOracle

Frequently asked questions

SAP background job management, answered

What is Symphony Background Job Management?

Symphony Background Job Management (BGM) is an agentic layer that schedules, monitors, and recovers SAP and non-SAP background jobs from one place. It runs time, event, and dependency-based scheduling, and when a job fails it triages the failure, recommends a safe action, routes approval, and records the evidence.

How does BGM differ from a scheduler like Control-M or Redwood RunMyJobs?

Traditional schedulers detect and alert on failures but leave the recovery manual. BGM adds a governed recovery layer on top of full scheduling: isAI classifies the failure and recommends the safe action, Maestro routes approval in Microsoft Teams, and the audit trail is captured as the work happens. The blog from schedulers to decision engines covers the wider shift.

What are isAI and Maestro?

isAI is the agentic engine that reads a failed job, rules out unsafe actions, and recommends the recovery. Maestro is the conversational layer inside Microsoft Teams where the accountable owner approves or adjusts that action. Together they turn a detected failure into an approved, logged recovery without manual triage.

Does BGM work with SAP S/4HANA and SAP Cloud ALM?

Yes. BGM runs across SAP ECC, SAP S/4HANA, and non-SAP systems, and integrates with SAP Cloud ALM for job scheduling and monitoring, as set out in the SAP Cloud ALM integration guide. It also connects to ITSM tools such as ServiceNow and JIRA, and routes approvals through Microsoft Teams.

Can Symphony replace an existing job scheduler?

In most cases yes. BGM consolidates SAP and non-SAP job orchestration onto one layer, covering scheduling, calendars, monitoring, maintenance windows, and alerting, so a separate scheduler licence can be retired. A short discovery session maps the current jobs to the governed model before any migration.