Home/Field Guide/Client extensions & APIs
CONCEPT 13
Batch, ERCs, and data migration
Promote configurations and move records with explicit ordering, reconciliation, and retries.
Split schema from records
Promote the model and supporting assets before importing entries. Check dependencies such as picklists, related Objects, roles, sites, and documents. Use stable external reference codes where the endpoint supports them. Numeric IDs from one database should not be presumed valid in another environment.
Use the generated Object batch operations where available or the Batch Engine / Data Migration Center for supported types. The documented generated /batch operations for custom Objects are company scoped. Inspect your target’s spec and supported migration path for site-scoped data. A batch client extension can package supported data or configuration artifacts for repeatable deployment.
Run a representative migration
- Prepare a manifest with source identifiers, counts, schema version, and dependencies.
- Load dependencies first. Run a small sample that includes a relationship and an attachment.
- Submit import work and retain its task identifier. Poll the task and inspect both task state and item-level errors.
- Reconcile by stable identifiers and validate role access. Rerun only using a strategy whose duplicate behavior you have verified.
- Keep an error report with failed ERCs and the reason for each failure, so operators can repair and replay the right rows.
Worked replay
If a 500-row import yields 480 valid rows and 20 missing picklist values, inspect the job’s error handling and stored data. Fix or map the 20 values, then replay using the operation and create/update strategy supported by the exact API. Compare totals and spot-check relationships. Do not assume a completed job means every source row was accepted.