A nightly job copies Dataverse product rows to an external catalog database. It currently reads every row each night, which is slow. The job must fetch only rows created, updated or deleted since its last run, without building any custom components in Dataverse. What should the developer implement?
Select an answer to reveal the explanation.
Short Explanation
Change tracking is like a bookmark the service hands you: come back with it and you get only what changed since then, deletions included. A modifiedon filter looks clever until someone deletes a row, because deleted rows don't have a modifiedon anymore. The plug-in staging idea works, but it's custom plumbing you were told not to build.
Full Explanation
Change tracking is a table-level setting that, once enabled, lets a client request only the differences since a previous point. The first request returns all rows along with a token; each later request sends the stored token and receives new or updated rows and deleted rows, plus a new token. In the Web API the token is carried in the delta link; in the SDK it is the DataToken used with RetrieveEntityChanges. Filtering on modifiedon catches creates and updates but can never return a row that has been deleted, so the catalog would keep products that no longer exist. Auditing records who changed what for compliance; it is not designed as a synchronization feed and adds parsing and retention concerns. A plug-in that writes to a staging table works but is a custom server-side component, which the requirement excludes, and it introduces new failure modes. Exam caveat: once change tracking is enabled it cannot be disabled, and a token that is older than the organization's change tracking retention, seven days by default, is rejected, so a job that misses runs must fall back to a full load. Operational check: run the job twice with no changes and confirm the second run returns nothing, then create, update and delete one product each and confirm all three appear.