What is Optimistic Concurrency in Microsoft Dataverse?

Optimistic concurrency is a mechanism in Microsoft Dataverse that protects business data from being unintentionally overwritten when multiple users, integrations, applications, or asynchronous processes modify the same record concurrently.

The fundamental problem is a classic lost update scenario.

Imagine a Customer Service agent opens an Account record at 10:00 AM. At the same time, an integration retrieves the same record. The agent changes the credit limit, while the integration changes the account classification.

If both applications retrieve the record before either update occurs and subsequently submit their changes, a conventional update operation can potentially allow one update to overwrite changes made by another process.

Optimistic concurrency addresses this by essentially saying:

"Update this record only if it is still the same version that I originally retrieved."

Microsoft Dataverse supports optimistic concurrency for applicable tables, and custom tables have optimistic concurrency enabled by default.

How does it work?

Conceptually, the process looks like this:

Step 1 — Retrieve record

Application retrieves:

Account
Name = Contoso
CreditLimit = 100,000
Version = 25

Step 2 — Another process modifies the record

The server updates the record:

CreditLimit = 125,000
Version = 26

Step 3 — Original application attempts update

The original application says:

Update Account
WHERE Version = 25

But the server now has:

Version = 26

Therefore, Dataverse rejects the operation rather than blindly overwriting the newer data.

With the SDK, this behavior can be requested through ConcurrencyBehavior.IfRowVersionMatches.

With the Dataverse Web API, optimistic concurrency can be implemented using HTTP ETags and the If-Match header.

Why is this important in Dynamics 365 CE?

It becomes particularly important in:

• Dynamics 365 integrations
• Custom plugins
• Power Automate flows
• External applications
• Bulk data processing
• Middleware integrations
• Mobile/offline scenarios
• Parallel asynchronous processing

Without concurrency control, an application can unknowingly overwrite a change that occurred after it retrieved the record.

What happens when there is a conflict?

A concurrency version mismatch is returned. The application should generally:

Detect conflict → Retrieve latest record → Re-evaluate business logic → Retry or request user intervention

The important point is that retrying blindly is not a concurrency strategy.

Suppose two users are modifying an account's credit limit. Automatically taking the latest value and writing yours again may simply recreate the conflict.

A mature implementation should determine whether the changes can be safely merged.