Bulk Data Load Jobs
Bulk Data Load Jobs is the Salesforce Setup monitoring surface for Bulk API jobs: the asynchronous, high-volume data import and export operations that tools like Data Loader, MuleSoft, dbt, Fivetran, and custom integrations submit through the Bulk API.
Definition
Bulk Data Load Jobs is the Salesforce Setup monitoring surface for Bulk API jobs: the asynchronous, high-volume data import and export operations that tools like Data Loader, MuleSoft, dbt, Fivetran, and custom integrations submit through the Bulk API. Each job processes records in batches (10,000 records per batch is the typical chunk size), runs in the background, and reports per-batch and per-record results. The Bulk Data Load Jobs page shows job status, throughput, errors, and lets admins abort a runaway job.
The page is the operational visibility layer for any data movement that goes through the Bulk API. It is where admins discover when a nightly integration job failed at 3 AM, why a migration script is still running after 6 hours, and which records failed and why. Most production Salesforce orgs have at least one Bulk Data Load Job running at any given time during business hours and several scheduled overnight; the page is essential operational furniture for any org with serious data integration.
Why the Bulk Data Load Jobs page is essential ops furniture for any integrated org
Where the page lives and what it shows
Setup, Environments, Jobs, Bulk Data Load Jobs. The page lists every Bulk API job in the past 7 days by default (configurable up to 30 days). Each row shows the operation (insert, update, upsert, delete, hardDelete, query), the object, the submitter, the start and finish times, the batch and record counts, and the success/failure summary. Clicking into a job shows per-batch detail with the same metrics at batch grain. The page does not show what data was processed; for that, pull the batch results CSV from the originating client (Data Loader, custom script).
How the Bulk API differs from the SOAP API
The Bulk API is designed for large data volumes (over 50,000 records per operation in practice). It processes records asynchronously in batches, returns immediately with a job ID, and lets the client poll for status. The SOAP API processes records synchronously with strict governor limits per call. The Bulk API has its own governor limits (different from synchronous) and its own throughput characteristics (typically 5,000 to 15,000 records per minute on most orgs, varying with object complexity and per-record automation). Most integrations over 10,000 records use the Bulk API; under that, SOAP or REST is usually simpler.
Bulk API V1 vs V2
Salesforce offers two versions of the Bulk API. V1 is the older API; it requires manual batch creation and per-batch monitoring. V2 is the newer API (released around 2018); it accepts a single CSV file and handles batch splitting internally, simplifying the client side significantly. Both versions show on the Bulk Data Load Jobs page. New integrations should use V2 unless they need a V1-specific feature; most clients (Data Loader 50+, MuleSoft, modern third-party tools) default to V2. Older custom scripts written before 2018 are typically on V1; migration to V2 is mostly a client-side change with no Salesforce-side configuration.
Job operations and the right choice per use case
Six operations: insert (create new), update (modify existing), upsert (insert or update based on external ID match), delete (soft delete to Recycle Bin), hardDelete (permanent delete bypassing Recycle Bin, requires Bulk API Hard Delete permission), query (extract records, the export operation). Pick the operation matching the intent; upsert for sync flows, hardDelete only when soft delete would not free storage in time. The hardDelete permission is gated for a reason; misuse can lose data with no recovery path.
Failure modes and the partial-success reality
Bulk jobs partially succeed often. A 100,000-record insert might have 99,500 successes and 500 failures. The failures are recorded per record with error messages; the successes apply normally. Common failures: validation rule rejections, duplicate detection blocks, foreign key lookups to records that do not exist, required field missing values. The reconciliation pattern: download the per-record results from the client, filter for failures, fix the underlying data issues, re-run the failed subset. Never re-run the original CSV after partial success because the successful records would re-insert and create duplicates.
Performance, parallelism, and throughput
Bulk API jobs run with controllable parallelism. Parallel mode (the default in V2) processes batches concurrently for higher throughput; Serial mode processes batches one at a time. Parallel is faster but can produce more locking contention on shared parent records; a 100,000-record Contact insert all linked to the same Account can block on the Account row lock and slow dramatically. Serial mode is slower but avoids the contention. The pattern: try Parallel first, fall back to Serial if locking errors appear in the results.
Monitoring, alerting, and the production discipline
The Bulk Data Load Jobs page is the post-hoc monitoring; for active jobs, the originating client typically has its own monitoring. For production integrations, build alerts on the AsyncApexJob and BulkApiJobInfo objects (queryable via SOQL) so failures trigger a Slack message or email rather than being discovered the next morning. Most large orgs build a dashboard that shows Bulk API job throughput, failure rates, and average completion time per integration; the dashboard catches degrading integrations before they become incidents.
How to operate Bulk Data Load Jobs in a production-integrated org
The pattern: use the Bulk API for the right scale, monitor through the page plus client logs, alert on failures, reconcile failed records explicitly. The page is the visibility layer; the operational discipline around it is the difference between an integration that works and one that drifts.
- Pick Bulk API V2 for new integrations
V2 is simpler to use and more efficient. Use V1 only for compatibility with older clients that have not migrated.
- Set parallelism based on the data shape
Parallel for unrelated records; Serial when records share parent records that produce locking contention. Start with Parallel, switch to Serial if locking errors appear.
- Use external IDs for upsert operations
Mark an integration-friendly field as External ID so upsert can match cleanly. Without an External ID, upsert falls back to Salesforce ID matching, which requires the integration to remember the Salesforce IDs.
- Monitor the Bulk Data Load Jobs page weekly
Pull the page weekly. Look for failed jobs, jobs running unexpectedly long, jobs from unknown sources. Each is a signal that needs investigation.
- Build alerts on AsyncApexJob and BulkApiJobInfo failures
For production integrations, an alert on job failure is the difference between hours and days of detection time. Flow plus Slack notification is the common pattern.
- Reconcile failed records explicitly
Download per-record results from the client. Filter for failures. Fix underlying data issues. Re-run only the failed subset; never the full original CSV.
- Audit Bulk API usage quarterly against integration inventory
Some Bulk API jobs come from integrations no one remembers. Quarterly audit identifies orphan integrations and assigns owners.
V1 or V2. V2 is the modern default; V1 is for compatibility with older clients.
insert, update, upsert, delete, hardDelete, query. Pick to match intent; hardDelete requires special permission.
Parallel (higher throughput, more locking risk) or Serial (slower, no locking risk). Start Parallel.
Records per batch. Default 10,000 in V2. Tune lower for memory-heavy work, higher for simple operations.
How long Bulk API job records persist. Default 7 days; configurable per org.
- Parallel mode produces locking contention on shared parent records. A bulk insert of children all linked to the same parent can slow dramatically; fall back to Serial.
- Bulk API jobs partially succeed often. Re-running the original CSV after partial success creates duplicates; always re-run only the failed subset.
- hardDelete bypasses the Recycle Bin. The data is gone; recovery requires backup. Gate the permission carefully and audit usage.
- Jobs from unknown integrations appear in the page. Some are legitimate (a former admin's script still running); some are not. Investigate each before assuming benign.
- Bulk API throughput varies with per-record automation. A target object with heavy triggers, validation rules, and Flow processes runs slower than a clean object; benchmark before scaling.
Trust & references
Cross-checked against the following references.
- Bulk API referenceSalesforce
- Bulk Data Load Jobs referenceSalesforce
Straight from the source - Salesforce's reference material on Bulk Data Load Jobs.
- Bulk API 2.0 and Bulk API Developer GuideSalesforce Developers
- Monitor Bulk Data Load JobsSalesforce Help
- Data LoaderSalesforce Help
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. Can a Salesforce admin configure Bulk Data Load Jobs without writing code?
Q2. Why is understanding Bulk Data Load Jobs important for Salesforce admins?
Q3. In which area of Salesforce would you typically find Bulk Data Load Jobs?
Discussion
Loading discussion…