Agentic Background Job Management

Q: Which systems and applications does BGM run jobs on?

BGM is API-first and runs jobs across a wide estate: • Applications. SAP ECC, S/4HANA, BW and BTP, and Salesforce, with selective restart inside job chains. • Databases. Oracle, HANA, MS SQL and DB2. • Infrastructure. Linux and Windows, and Azure, AWS and GCP cloud jobs. Replay RPA drives tools with no API, and the Script Appstore runs shell, Python, Ansible and Terraform steps natively.

One platform

One platform for every background job

Symphony BGM administers, monitors, maintains and alerts on background jobs across every enterprise system from one platform, with an agentic isAI layer that recovers them when they fail. The five capabilities below are what the platform ships with.

Administration

Automate business processes across SAP and enterprise applications like Salesforce
Schedule jobs once, periodically or on recurring intervals
Factory and business calendars for holidays, weekends and shifts
Event-driven job scheduling
Selective job restart within job chains, including SAP job steps

Monitoring

Centralized view of jobs and job chains
Realtime and analytical dashboards, current and past jobs
Runtime analytics and future forecasting
Monitoring through SAP Cloud ALM, logs flow direct

Maintenance

Suspend jobs and job chains on schedule
Auto-execute or skip suspended jobs after maintenance
Calendar view of schedules, adjustable for extended windows
High-availability with near-zero-downtime (nZDT) for workflows maintained in Symphony

Alerts

Alerts on job, job chain and SAP job step failure
Long-running job and missed-run detection
Email and Outlook notifications, plus an alert inbox
Interactive updates in Microsoft Teams via Maestro

Auto-recovery

Retriggers failed jobs intelligently
Holds downstream jobs when a predecessor overruns
Routes workflows dynamically on job logs and outcomes
Agentic isAI, context-aware and compliant by design

Recovery, powered by isAI

How does Symphony recover a failed job?

Scheduling and monitoring run every day. Recovery is the moment that separates a governed estate from an out-of-hours firefight, and it is where a scheduler reaches its limits. isAI reads the failure, ranks the safe action, Maestro routes approval in Microsoft Teams, and Symphony recovers and records the evidence.

01

Detect

The job and every dependency, not only the alert

02isAI

Recommend

Classifies the failure and ranks the safe action

03Maestro

Approve

Routes the decision to the owner in Microsoft Teams

04isAI

Recover

Runs the approved action, and only that action

05

Audit

Failure, decision, approval and outcome logged live

Governed recovery

A person approves, every time

isAI ranks the safe action and Maestro routes it to the accountable owner in Microsoft Teams. Symphony runs only what was approved, so nothing reaches production without a human sign-off.

Autonomous auto-recovery

Safe actions run within policy

Where a rule allows it, Symphony acts on its own: it retriggers a failed job, holds downstream work when a predecessor overruns, and reroutes based on job logs and outcomes, all logged.

Auto-recovery scope is defined per estate. Detailed policy patterns are walked through in a session.

After the alert, manually today

After the alert, with Symphony BGM

Alert raised, then it waits

Job and dependency context captured

Owner searched manually

Owner mapped by policy

Restart decision delayed

isAI ranks the safe 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

Job failure runbooks

Which job failures does Symphony handle?

Each runbook is a failure operations teams meet in production, from a cancelled payment run to a database load that overruns its window. Step through one, then toggle from manual recovery today to Symphony, where isAI ranks the action, Maestro approves it in Microsoft Teams, and the audit trail is captured as it happens.

Symphony · Runbook 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 are blocked, and a blind restart risks paying twice before the bank cutoff.

Detect

Manual watch

Auto-detected

Recommend

Manual triage

isAI recommends

Approve

Chase sign-off

Owner approves

Recover

Manual action

Runs approved action

Audit

Rebuilt after

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.

[02:16:40] APPROVE: routed to AP / Treasury in Microsoft Teams, 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.

isAI, suggested actions

isAI recommends Resume via F110, After Termination, draw up again

option Re-schedule the payment run double-pay risk

option Repeat the run in SM37 double-pay risk

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

Manual watch

Auto-detected

Recommend

Manual triage

isAI recommends

Approve

Chase sign-off

Owner approves

Recover

Manual action

Runs approved action

Audit

Rebuilt after

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 in Microsoft Teams, 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.

isAI, suggested actions

isAI recommends Selective restart from step 4 only

option Rerun the whole chain reprocesses 1 to 3

option Skip step 4 and continue data gap

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: Database load overruns its window (DWH_NIGHTLY_LOAD (SSIS))

A nightly warehouse load runs well over baseline and holds a blocking lock, and the 06:00 reporting refresh waits behind it.

PRD-DWH SQL Agent · session SEV-2 Owner: Data platform + DBA · SLA: Reporting SLA 06:00

Business impact: The morning reporting refresh stalls behind the load, and dependent dashboards miss the 06:00 SLA.

Detect

Manual watch

Auto-detected

Recommend

Manual triage

isAI recommends

Approve

Chase sign-off

Owner approves

Recover

Manual action

Runs approved action

Audit

Rebuilt after

Logged live

# LOG_VIEWER # TRACE_ENABLED

[03:40:00] ALERT: DWH_NIGHTLY_LOAD 190% over baseline.

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

[05:11:00] TRIAGE: sp_who2, a blocking session on the staging table.

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

[05:58:00] RECOVERY: session killed and load restarted late, SLA breached.

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

[03:40:04] DETECT: blocking session identified, dependent refresh mapped.

[03:40:09] RECOMMEND: three options ranked, restart from last checkpoint preferred.

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

[03:42:10] RECOVER: session cleared, load restarted from checkpoint, queue rebalanced.

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

isAI, suggested actions

isAI recommends Restart from the last committed checkpoint

option Extend the reporting window SLA at risk

option Kill and reload from the top reprocesses all

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

With SymphonySLA held, the load resumes from its checkpoint with no manual session 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

Manual watch

Auto-detected

Recommend

Manual triage

isAI recommends

Approve

Chase sign-off

Owner approves

Recover

Manual action

Runs approved action

Audit

Rebuilt after

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.

isAI, suggested actions

isAI recommends Release in the captured dependency order

option Bulk release every suspended job order lost

option Hold all jobs for manual review delay

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: File-triggered job stops firing (BANK_STMT_IMPORT (file event))

A file-triggered import stops firing after an SFTP credential rotation, and no failure is raised because the trigger never runs.

PRD-INT SFTP · watcher SEV-3 Owner: Integration owner · SLA: Files land 02:00 to 06:00

Business impact: A statement file lands but nothing picks it up, and reconciliation runs short until someone notices days later.

Detect

Manual watch

Auto-detected

Recommend

Manual triage

isAI recommends

Approve

Chase sign-off

Owner approves

Recover

Manual action

Runs approved action

Audit

Rebuilt after

Logged live

# LOG_VIEWER # TRACE_ENABLED

[--:--:--] NO ALERT: BANK_STMT_IMPORT trigger not firing, nothing runs.

[+3 days] DISCOVERY: reconciliation short, missing statements noticed.

[+3d 10:00] TRIAGE: file watcher, a credential rotation broke the SFTP poll.

[+3d 11:30] RECOVERY: credential fixed, files reprocessed by hand, catch-up unclear.

[02:00:00] WATCH: expected file event for BANK_STMT_IMPORT is due.

[02:15:00] DETECT: time-since-last-trigger breach, absence flagged.

[02:15:04] RECOMMEND: re-authenticate the SFTP poll, reprocess landed files.

[07:10:00] APPROVE: catch-up scope confirmed by the integration owner.

[07:12:00] RECOVER: SFTP credential refreshed, landed files reprocessed in order.

[07:12:03] AUDIT: stop time, fix, and files reprocessed logged.

isAI, suggested actions

isAI recommends Re-authenticate the SFTP poll, reprocess landed files

option Wait for the next scheduled window gap grows

option Reprocess by hand, leave the trigger down recurs

TodayA trigger that never fires cannot raise a flag, so the gap stays invisible until reconciliation breaks.

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

Beyond the scheduler

Where Symphony goes deeper than a scheduler

Workload automation has outgrown the scheduler twice, first for dependencies, now for decisions. Symphony carries the scheduling depth a real batch estate needs, the reach to run any job anywhere, and the agentic layer that acts when a schedule alone cannot.

Advanced scheduling

The controls a real batch estate needs, well past cron and a calendar.

Delay nodes with buffer windows, cross-midnight chains handled
Missed-run options: execute all, last, skip or none, with surge warnings
Factory and inversed-holiday calendars, multi-timezone
Reserve throttle, isolated capacity for critical jobs

Universal coverage

One canvas for application, database, operating-system and cloud jobs.

API-first onboarding of any enterprise application or infrastructure job
Replay RPA drives tools that have no API, no blind spots
Script Appstore runs shell, Python, Ansible and Terraform natively
Group suspend and release, direct SAP Cloud ALM integration

Agentic AI

isAI and Maestro turn scheduling and recovery into a conversation.

Conversational scheduling in natural language
Maestro as a native app inside Microsoft Teams
MCP server and client, bidirectional agent interoperability
A2A protocol and ML forecasting for runtime and anomalies

Enterprise-grade by default

Governance, security and AI, built in, not a paid tier

Role-based access controlGoverns every process engine, calendar, job and dashboard

Downloadable audit trailsEvery change, with user, timestamp and what changed

Vault integrationAzure Key Vault, AWS Secrets Manager and GCP Secret Manager

Workflow versioningApproval-gated publishing, every change reviewed before live

Custom dashboardsRuntime analysis and job monitoring, configurable out of the box

SAP Cloud ALM and ITSMUnified observability, zero-touch via ServiceNow and JIRA

Watch it work

A failed job, recovered and approved in two minutes

A scheduled job fails on a reorganisation error at 2am. Watch Symphony rank the safe action, route approval in Microsoft Teams, and recover the job, with every step written to the audit trail as it happens.

Proven in production

Enterprise scale, migrated without disruption

Symphony BGM runs more than 7 million background jobs a month across live enterprise estates in utilities, food and dairy, including migrations from established schedulers such as Control-M and UC4, and job management within SAP on RISE transformations.

Utilities · Australia

Migrated off Control-M in a fast-tracked window

An electricity distribution network operator moved its SAP S/4HANA and Microsoft SQL Server jobs off Control-M into Symphony BGM, carrying across job, calendar and event-based conditions and SLA-driven workloads.

190unique production jobs across the estate

2.5M+job executions per month

100jobs in one complex workflow

Agenticnow positioned for orchestration

Food · Europe

Migrated off UC4 with zero go-live issues

An organic food company moved its SAP ERP and SAP BW jobs off UC4 into Symphony BGM, redesigned and validated before cutover, phased module by module, with event-based and file-based event jobs carried across.

278unique production jobs across the estate

510K+job executions per month

Zerogo-live issues

ITSMand auto-decisioning unlocked

Dairy · Global

Job management through an SAP on RISE program

A global dairy cooperative runs Symphony BGM across 12 SAP production landscapes as part of a broader SAP on RISE engagement, with jobs onboarded to support an S/4HANA transformation and cutover automation.

610unique production jobs across the estate

4.4Mjob executions per month

12SAP production landscapes

3-yeartransformation program

See recovery run on a live estate

Share where scheduling, recovery and monitoring stand today. A 30-minute session explores the fit for the jobs already in place, and what an agentic layer would change.

Book a walkthrough

30-minute discovery session*

Frequently asked questions

Agentic background job management, answered

What is Symphony Background Job Management?

Symphony Background Job Management (BGM) is an agentic platform that schedules, administers, monitors and maintains background jobs across enterprise applications, databases, operating systems and cloud. When a job fails, an agentic layer, isAI and Maestro, recommends a safe action, routes approval, recovers the job and records the evidence.

Which systems and applications does BGM run jobs on?

BGM is API-first and runs jobs across a wide estate:

Applications. SAP ECC, S/4HANA, BW and BTP, and Salesforce, with selective restart inside job chains.
Databases. Oracle, HANA, MS SQL and DB2.
Infrastructure. Linux and Windows, and Azure, AWS and GCP cloud jobs.

Replay RPA drives tools with no API, and the Script Appstore runs shell, Python, Ansible and Terraform steps natively.

Can Symphony migrate jobs from Control-M or UC4?

Yes. Symphony teams have migrated live production estates off Control-M and UC4, with jobs redesigned and validated before cutover, phased by module, and delivered with zero go-live issues on a recent migration. Complex scheduling patterns, event-triggered jobs and SLA-driven workloads are carried across.

How much does the agentic layer do on its own?

In governed recovery, isAI recommends the safe action, Maestro routes approval in Microsoft Teams, and Symphony runs only what was approved, then logs it. Autonomous auto-recovery runs only within rules set in advance, retriggering a failed job, holding downstream work when a predecessor overruns, and rerouting based on job logs.

Does BGM integrate with SAP Cloud ALM and ITSM?

Yes. Job execution logs flow directly into SAP Cloud ALM for unified monitoring and observability, as set out in the SAP Cloud ALM integration guide. BGM also connects to ITSM tools such as ServiceNow and JIRA, and routes alerts and approvals through Microsoft Teams and Outlook.

Background job management that acts, not just alerts

Thanks, the request is in

One platform for every background job

Administration

Monitoring

Maintenance

Alerts

Auto-recovery

How does Symphony recover a failed job?

Detect

Recommend

Approve

Recover

Audit

A person approves, every time

Safe actions run within policy

Which job failures does Symphony handle?

Where Symphony goes deeper than a scheduler

Advanced scheduling

Universal coverage

Agentic AI

A failed job, recovered and approved in two minutes

Enterprise scale, migrated without disruption

Migrated off Control-M in a fast-tracked window

Migrated off UC4 with zero go-live issues

Job management through an SAP on RISE program

See recovery run on a live estate

Agentic background job management, answered

What is Symphony Background Job Management?

Which systems and applications does BGM run jobs on?

Can Symphony migrate jobs from Control-M or UC4?

How much does the agentic layer do on its own?

Does BGM integrate with SAP Cloud ALM and ITSM?