What's changed: Created PL-400 Chapter 5, completing the textbook (domain: Develop integrations): publishing/consuming Dataverse events (IServiceEndpointNotificationService, webhook registration in the Plug-in Registration Tool, Azure Service Bus queues/topics, Azure Event Hub, choosing listening options) and data synchronization with Dataverse (change tracking delta retrieval, alternate keys, the UpsertRequest message).
5.2Data synchronization with Dataverse
Understand delta retrieval via change tracking, alternate keys, and synchronization with the UpsertRequest message.
Keeping an external system and Dataverse efficiently consistent requires delta retrieval and reliable matching.
5.2.1Change tracking
Enabling change tracking lets you efficiently retrieve only rows changed since the last sync (the delta). You no longer fetch everything each time, making large-data sync practical. Enable per table; the sync process keeps the prior token to fetch deltas.
5.2.2Alternate keys and UpsertRequest
External systems often don’t know Dataverse’s GUID primary key, so define alternate keys to uniquely identify a record by the external key (e.g., order number). For sync, use the UpsertRequest message to update if it exists, create if not in a single operation. This avoids "retrieve-then-branch," reducing conflicts and round-trips.
Cues: "efficiently retrieve only the delta since last time" = change tracking. "identify a record by the external system’s key" = alternate keys. "update if exists, create if not in one op" = UpsertRequest. More efficient than full fetch or retrieve-then-branch.
Watch the mix-ups: (1) Change tracking (delta) vs full retrieval. (2) Alternate keys (identify by external key) vs the GUID primary key. (3) UpsertRequest (single op with existence check) vs CreateRequest/UpdateRequest (separate). (4) Change tracking must be enabled per table.
5.2.3Section summary
- Change tracking efficiently retrieves only the delta (avoids full fetch)
- Alternate keys uniquely identify records by the external system’s key
- UpsertRequest updates if exists, creates if not, in one operation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. When syncing a large Dataverse table externally, you want only rows changed since last time, not a full fetch each run. Best?
Q2. Because the external system doesn’t know the Dataverse GUID, you want to identify records uniquely by an external key like order number. Best?
Q3. You want sync that updates if a record exists and creates if not, in a single operation. Best message?
Q4. Which is a correct prerequisite for using change tracking?
Q5. Which correctly distinguishes UpsertRequest from CreateRequest/UpdateRequest?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.