A scheduled integration sends the same batch of product records from an ERP system to Dataverse every hour. A product may or may not already exist in Dataverse, and the job must be safe to rerun after a failure without creating duplicates. The ERP product code is an active alternate key. Rows must be written without a separate existence check. What should the developer use?

UpsertRequest takes an entity identified by its primary key or an alternate key. Dataverse looks for a matching row; if one exists it is updated, and if none exists a new row is created, all in a single request. Because the ERP product code is an active alternate key, rerunning the hourly batch updates the same rows instead of creating new ones, which makes the job idempotent. Retrieving first and then choosing Create or Update works, but it doubles the requests and introduces a race between the read and the write; it is also the separate existence check the requirement excludes. CreateMultiple with error handling relies on failures to steer logic, wastes requests, and complicates batch error handling. Deleting and recreating rows changes their GUIDs, breaks lookups and activity history that reference them, and fires delete and create logic every hour. Exam caveat: for large volumes, UpsertMultiple applies the same behavior to many rows in one request, but the key requirement is unchanged. Operational check: run the batch twice against a test environment and confirm the product count is unchanged after the second run, and that changed ERP values were updated on the existing rows.