What Are Staging Tables?
Staging tables are temporary holding areas where incoming data lands before being applied to your target tables. This two-step process provides several important benefits:
• Data Integrity: Changes are validated before affecting your production data
• Atomic Operations: All changes from a sync batch are applied together or not at all
• Traceability: Each batch can be tracked and audited
• Recovery: If something goes wrong, staging data can be reprocessed without re-fetching from the source
How Staging Works
During each synchronization:
1. Data Mission Sync fetches changes from Dataverse (inserts, updates, deletes)
2. Changes are written to the staging table with operation markers
3. The Apply process reads staging data and merges it into the target table
4. Staging data is cleared after successful application
Staging Table Naming
Staging tables follow the naming convention stage_{entity} in your configured schema. For example:
• dbo.stage_account — Staging table for the account entity
• dbo.stage_contact — Staging table for the contact entity
• replica.stage_lead — Staging table for lead (if using 'replica' schema)
Staging Table Columns
Staging tables contain the same data columns as target tables, plus additional metadata columns for processing:
| Column | Description |
| __op | CHAR(1) — Operation type: 'I' (Insert), 'U' (Update), or 'D' (Delete) |
| _batch_id | Identifier linking records to a specific sync batch for traceability |
| _received_utc | Timestamp when the record was received from the source |
| 💡 Note: Staging tables are managed automatically by Data Mission Sync. You generally don't need to query them directly, but they're available for troubleshooting if needed. | |