Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Bulk Data Load Jobs entry
How-to guide

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.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 18, 2026

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

API versionremember

V1 or V2. V2 is the modern default; V1 is for compatibility with older clients.

Operationremember

insert, update, upsert, delete, hardDelete, query. Pick to match intent; hardDelete requires special permission.

Parallelism moderemember

Parallel (higher throughput, more locking risk) or Serial (slower, no locking risk). Start Parallel.

Batch sizeremember

Records per batch. Default 10,000 in V2. Tune lower for memory-heavy work, higher for simple operations.

Retention windowremember

How long Bulk API job records persist. Default 7 days; configurable per org.

Gotchas
  • 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.

See the full Bulk Data Load Jobs entry

Bulk Data Load Jobs includes the definition, worked example, deep dive, related terms, and a quiz.