Monitor Workflow Services
Monitor Workflow Services is the Setup page in Salesforce Industries that tracks the runs of Data Processing Engine definitions and Batch Management jobs.
Definition
Monitor Workflow Services is the Setup page in Salesforce Industries that tracks the runs of Data Processing Engine definitions and Batch Management jobs. Each run produces a batch job record, and the page lets you watch that record while the run is in progress and review it after the run ends. You reach it from Setup by searching for Monitor Workflow Services in the Quick Find box.
The page is the single place to confirm whether a definition run or batch job actually finished, how many records it processed, and which records it could not. It groups each run into a Details view, a Tasks view that lists the parts the run was split into, and a Failed Records view. Access is limited to users with the System Administrator profile, since the data exposed here spans the whole org.
How Monitor Workflow Services tracks a run
What the page actually monitors
Monitor Workflow Services is not a general automation monitor. It is scoped to two Industries features that share the same batch engine: Data Processing Engine and Batch Management. Data Processing Engine reads data from Salesforce objects, CRM Analytics datasets, or other sources, transforms it, and writes the result back to target objects. Batch Management runs a business flow over a large set of records in batches. Both produce a batch job each time they run, and Monitor Workflow Services is where those jobs show up. If you are looking for the queue of pending time-dependent Workflow Rule actions, that is a different screen called Time-Based Workflow, not this one. The naming is close enough to cause confusion, so it helps to remember the rule: Monitor Workflow Services is about Data Processing Engine and Batch Management batch jobs, period. The page reads from standard batch job objects, so the same run history is also queryable through SOQL and the API if you want to build your own reporting on top of it.
The three tabs on a run
When you open a batch job from Monitor Workflow Services, the record breaks into three views. The Details tab shows the run metadata: when it started, its current status, and the values supplied for the business flow and batch job input variables at run time. This is where you confirm a run used the parameters you expected. The Tasks tab lists the batch job parts. A single run is split into parts so the platform can process records in chunks, and each part has its own status and record counts. Click into a part to see how that slice of the run behaved. The Failed Records tab lists the records the job could not process, which is the first place to look when the processed count is lower than the source count. Together these three views answer the practical questions an admin has after kicking off a run: did it finish, how much did it move, and what got left behind.
The phases inside a Data Processing Engine run
A Data Processing Engine definition run moves through distinct phases, and Monitor Workflow Services lets you watch them unfold. First the engine syncs the data sources on the runtime platform, pulling the source records into the processing layer. Then it applies the transformation logic you defined, which can include joins, aggregations, formulas, and filters. Finally it writes the results back to the target objects or datasets. Each phase shows up as work on the run, so a run that stalls during the write-back phase points you at a different problem than one that fails during the sync. The page surfaces the count of records processed and written back, a comparison of the latest run against the previous one, and the reason the most recent run failed. That last detail matters because Data Processing Engine failures are often data-shaped (a required field went null, a lookup did not resolve) rather than configuration-shaped, and the failure reason on the run is what tells them apart.
Reading a Batch Management job
Batch Management runs a business flow across a large record set, splitting the work into batches so each chunk stays inside platform limits. In Monitor Workflow Services, a Batch Management job looks much like a Data Processing Engine run: a Details tab with the input variables, a Tasks tab with the parts, and a Failed Records tab. The difference is what the job is doing. A Batch Management job is executing flow logic on each record, so a failure usually traces back to a fault inside the business flow or a record that did not meet a path condition. Use the Tasks tab to find which part contains the failures, then the Failed Records tab to see the specific records and the errors they hit. Because the job is recorded persistently, you can come back hours later and still see exactly which records a batch run touched. That makes Monitor Workflow Services the audit trail for a large data operation, not just a live progress bar.
A worked troubleshooting example
Say a Financial Services Cloud team runs a Data Processing Engine definition nightly to roll household financial totals onto a summary object. One morning the dashboard numbers look stale. The admin opens Monitor Workflow Services and finds the latest batch job for that definition. The Details tab shows the run completed, so it did not hang. The processed count, though, is 4,900 against a source of 5,000, which means 100 records did not write back. The Tasks tab points to the part holding the gap, and the Failed Records tab shows those 100 records failed because a lookup to an account broke after a merge earlier that day. Now the fix is obvious: repair the broken lookups, not touch the definition. Without the page, the admin would have seen only that the dashboard was wrong and guessed at the cause. With it, the failure reason and the exact failed records turn a vague symptom into a precise data fix. This is the everyday value of the page: it converts a silent batch run into something you can inspect.
Cleaning up old runs
Batch job records accumulate every time a definition or job runs, and in an org with nightly Data Processing Engine schedules that adds up fast. Monitor Workflow Services lets you delete completed, failed, or canceled runs you no longer need. Deleting a run also removes its associated tasks, so the cleanup is whole rather than partial. Be deliberate about it. The run history is your record of what a batch operation did and when, so deleting a failed run before you have read its failure reason throws away the evidence you would use to debug it. A sensible habit is to read and resolve failures first, then prune. Some teams keep a rolling window (the last 30 or 90 days of runs) and delete older ones to keep the list readable. Because the underlying batch job data is also reachable through the API, an org that needs a longer retention window can export run summaries before deleting, rather than keeping every record in the page forever.
Where it fits among Salesforce monitoring tools
Salesforce has several monitoring surfaces, and they do not overlap. Monitor Workflow Services covers Data Processing Engine and Batch Management runs specifically. Apex Jobs under Setup covers asynchronous Apex (Batchable, Queueable, Schedulable). Time-Based Workflow covers queued time-dependent Workflow Rule actions, which is the legacy automation being retired. Paused and Waiting Interviews covers scheduled and waiting Flow interviews. Knowing which screen owns which feature saves real time, because looking for a Data Processing Engine failure in the Apex Jobs list will turn up nothing. For compliance-grade history that outlives the operational run records, Salesforce Shield Event Monitoring captures a separate, tamper-resistant event stream. Monitor Workflow Services is operational visibility for the Industries batch engine, and Shield is the archival layer. A team running large Industries data jobs typically uses Monitor Workflow Services day to day and reaches for Shield only when an auditor needs proof that something ran on a given date.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Monitor Workflow Services.
- Monitor Data Processing Engine Definition RunsSalesforce
- Monitor Your Batch JobsSalesforce
Hands-on resources to go deeper on Monitor Workflow Services.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which Salesforce tool has Salesforce recommended as the future of automation?
Q2. When should you consider using Monitor Workflow Services in your Salesforce org?
Q3. What is the main advantage of using Monitor Workflow Services over writing Apex code?
Discussion
Loading discussion…