Dataverse UpsertMultiple Action Failing for Mixed New/Existing Records with Alternate Keys

(1) Share

Report

Posted on by JL-23101257-0

I'm encountering an issue with the UpsertMultiple action in Dataverse. The behavior seems inconsistent when handling batches that contain both new and existing records.

Scenario:

Table has an alternate key configured (e.g., dev_transactionid)

Batch operations need to handle both new and existing records

Can't pre-determine which records exist without individual GET requests

Issue:
When using UpsertMultiple (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/reference/upsertmultiple?view=dataverse-latest):

If @odata.id is included in the payload:

{ "Targets": [{ "@odata.type": "Microsoft.Dynamics.CRM.dev_transaction", "dev_transactionid": "123", "dev_name": "Example", "@odata.id": "dev_transactions(dev_transactionid='123')" }] }
- ✅ Works for updating existing records
- ❌ Fails for new records with unexpected error

If @odata.id is omitted:

{ "Targets": [{ "@odata.type": "Microsoft.Dynamics.CRM.dev_transaction", "dev_pmstransactionid": "123", "dev_name": "Example" }] }
- ✅ Works for inserting new records
- ❌ Fails for existing records with duplicate key error

Expected Behavior:
UpsertMultiple should handle both scenarios since that's the purpose of an upsert operation.

All workarounds fail because any batch likely contains a mix of new and existing records, and we can't practically pre-check existence of each record as that would be very inefficient.

Is this expected behavior? If so, what's the recommended approach for handling bulk upsert operations with alternate keys?

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (3)

Answers (0)

Suggested answer

danglotor 5 on at

Like (1)

Report

I had the same issue.

The issue for us was, that our targets contained the column definition also for the columns which are part of the alternate key, which I also see in your example.

In your example you MUSN'T specify the dev_transactionid as a separate attribute for the target. so each target should be only this:

{
"@odata.type": "Microsoft.Dynamics.CRM.dev_transaction",
"dev_name": "Example",
"@odata.id": "dev_transactions(dev_transactionid='123')"
}

The >>"dev_transactionid": "123",<< line removed.

We solved the issue after we found this documentation: https://learn.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/dn932135(v=crm.8)?redirectedfrom=MSDN
Specifically this image

I have no proof of this, but I suspect that the step which fills in the alternate key attributes based on alternate key specified value simply fails, because the attributes already do have value. (upper right corner in the image)

1 people found this reply helpful.

Was this reply helpful? Yes No
JA-16101953-0 3 on at

Like (0)

Report

Thanks danglotor !! Spent hours debugging before stepping into your post…

if someone from Microsoft stop by, please add this « little » detail to your documentation ;).

Was this reply helpful? Yes No
Ram Prakash Duraisamy 5,597 Super User 2025 Season 2 on at

Like (0)

Report

Hi @JL-23101257-0

I think this helps if @odata.id is null then consider this as Create Record if @odata.id is not null then treat it as Upsert or Update which means existing record

Please mark as answer if my suggestion helps.
Subscribe here for More Useful videos : https://www.youtube.com/@rampprakash3991

Was this reply helpful? Yes No