Microsoft Dataverse

If you are maintaining this today

Dataverse works differently from every other version on this site. It isn’t installed, there’s no release to stay on, and there’s no end-of-support date to look up. Microsoft’s developer guide says plainly that Dataverse isn’t available on-premises. The guide also leaves out options that only exist on-premises or on internet-facing deployments.

What you get instead is continuous change:

• Weekly minor service updates, rolled out region by region.
• Two major release waves a year, in April and October. Microsoft describes them as backward compatible, with disruptive user-experience features turned off by default so administrators can test first.

So the date on this page matters more than on the historical ones. Anything here was checked against Microsoft’s documentation on the date shown and should be rechecked against the current page before you rely on it.

The names changed, the APIs didn’t

The Power Apps interface renamed the concepts, but the developer surfaces still use the old names:

Power Apps interface	SDK for .NET	Web API
Table	Entity	EntityType
Column	Attribute	Property
Row	Record	Record
Choices	OptionSet / Picklist	OptionSet
Yes/No	Boolean	Boolean

What changed for customizers

Area	The on-premises habit	Dataverse
Hosting	Your servers, your upgrade schedule	Online only, updated by Microsoft
.NET client	CrmServiceClient, OrganizationServiceProxy	ServiceClient in Microsoft.PowerPlatform.Dataverse.Client
Authentication	Active Directory, claims, the “Office365” WS-Trust type	Microsoft Entra ID through MSAL; WS-Trust retired
Plug-in deployment	On-disk or database, sandbox or not	Sandbox and database only; dependent assemblies as a NuGet package
Custom messages	Custom process actions	Custom APIs, for logic defined in code
Automation	Classic workflows and dialogs	Power Automate recommended; dialogs and task flows deprecated
Form script	Xrm.Page	formContext
Integration load	Limited by your own hardware	Service protection limits per user

Endpoints, and what happened to the old ones

Sources: Microsoft’s “Use the Dataverse SDK for .NET”, “Transition apps to Dataverse ServiceClient”, “Use the Microsoft Dataverse Web API”, “Compose HTTP requests and handle errors”, and its deprecation announcements.

• The Web API is OData v4.0, and its current version segment is v9.2. Microsoft says code written against v9.0 keeps working when it references v9.0 in the URL. Under the Web API, every data operation still goes through the organization service, whose messages are what the event framework and your plug-ins respond to.
• The 2011 SOAP endpoint is deprecated, not removed. Microsoft’s SDK documentation says it keeps working and stays supported until it is removed. Updated SDK assemblies will be available before then. The removal announcement for the OData v2 service notes separately that no date has been announced for the SOAP endpoint. The ServiceClient timeline lists, at an unspecified future date, a shutdown of the SOAP endpoint for client applications that don’t use CrmServiceClient or ServiceClient. Both service clients are documented to keep working afterwards. Code that talks to the endpoint any other way, such as hand-built WCF proxies or raw SOAP, is the code at risk. The full history of the endpoints is on CrmService to the Web API.
• The OData v2 organization data service is due for removal. The original date was 11 November 2022, extended to 30 April 2023, and then removal was deferred with no final date yet announced. Microsoft’s instruction is to move that code to the Web API now.
• The “Office365” authentication type is gone. Microsoft deprecated WS-Trust for OrganizationServiceProxy and CrmServiceClient on 4 February 2020, and announced its retirement for all new and existing environments from April 2022.
• ServiceClient replaces CrmServiceClient for applications. It uses MSAL rather than ADAL and supports .NET Core. Microsoft ended ADAL support in December 2022, although CrmServiceClient is documented to keep working. The member signatures are largely the same, so moving is mostly a package and class-name change.

Service protection limits

Source: Microsoft’s “Service protection API limits”.

On-premises, an integration was limited by your own hardware. In Dataverse, limits apply per user, over a five-minute sliding window:

Limit	Within five minutes
Number of requests	6,000
Combined execution time	20 minutes (1,200 seconds)
Concurrent requests	52, possibly higher

Going over returns 429 Too Many Requests from the Web API, with a Retry-After header. The SDK for .NET puts Retry-After in the fault’s ErrorDetails. Xrm.Tooling.Connector versions after 9.0.2.16 pause and retry by themselves.

Microsoft’s advice is not to calculate a safe rate. Increase gradually until you hit the limit, then let Retry-After pace you. Operations that plug-ins and custom workflow activities perform don’t count, because they run in the sandbox service and don’t use the public endpoints.

Plug-ins

Sources: Microsoft’s Dataverse topics “Use plug-ins to extend business processes”, “Write a plug-in”, “Build and package plug-in code”, “Register a plug-in” and “Transition apps to Dataverse ServiceClient”.

The pipeline itself carries on from earlier versions: see event pipeline stages and Depth, ParentContext and CorrelationId. What changed is the deployment and some rules:

• Sandbox and database only. The isolation mode and assembly location options at registration exist for on-premises; for Dataverse, accept Sandbox and Database.
• Write plug-in classes stateless. The platform caches and reuses instances, so a field that holds a service or context data can leak into the next call.
• Use the organization service inside plug-ins. Microsoft says the Web API isn’t supported there, and the user is already authenticated.
• Plug-ins have a hard time limit, and Microsoft describes synchronous plug-ins as needing to complete quickly because users wait on them.
• Plug-ins still target .NET Framework. The sandbox supports .NET Framework 4.8, and the older 4.6.2 and 4.7 targets are still accepted. The ServiceClient transition doesn’t affect plug-ins, which keep using the CoreAssemblies packages.
• Packaging. An assembly can’t be larger than 16 MB. Without the dependent assemblies capability it must be signed. With it, your plug-in and its dependencies are uploaded as a NuGet package stored in the PluginPackage table. ILMerge isn’t supported.
• Tooling. Microsoft now points to Power Platform Tools for Visual Studio and the Power Platform CLI: pac plugin init creates a project with a generated PluginBase class, and pac tool prt opens the Plug-in Registration tool. Tracing to PluginTraceLog must be enabled in the environment before it records anything.

Custom APIs

Source: Microsoft’s “Create and use custom APIs”.

The custom actions introduced in CRM 2013 still exist as custom process actions. Custom APIs are Microsoft’s developer-focused alternative. They define a message with typed request parameters and response properties, can be bound to a table, can be a function or an action, can require a privilege, and use a plug-in for their main logic.

Automation

Sources: Microsoft’s “Replace classic Microsoft Dataverse workflows with flows” and its deprecation announcements.

• Power Automate is the recommended route for new automation. Microsoft suggests reviewing existing classic background workflows for replacement with flows. Which replacement fits which workflow is on What should my classic workflow become?
• Dialogs were deprecated, with removal announced for 1 December 2020. Business process flows or canvas apps were the suggested replacements.
• Task flows were deprecated, with removal announced for 1 October 2021.
• The legacy business process flow columns are deprecated. Writing to StageId or TraversedPath on the record itself, or using the SetProcess action, isn’t supported and doesn’t keep the flow’s state consistent. Use the business process flow table’s own rows instead. Code written the CRM 2013 way needs changing here.

Form scripting

Source: Microsoft’s “Client API form context”.

Xrm.Page is deprecated. Get the form from the execution context with executionContext.getFormContext(), and tick “Pass execution context as first parameter” on the event handler. Xrm.Page is still supported for backward compatibility. Microsoft commits to announcing any removal at least six months ahead. Ribbon commands get their form context differently from form events. The 9.x on-premises page lists the other deprecated client APIs and their replacements. How form scripting got here from CRM 3.0 is on crmForm to Xrm.Page to formContext.

Solutions and ALM

Source: Microsoft’s “Overview of application lifecycle management with Microsoft Power Platform”.

Solutions are still how components move between environments, and they now carry more kinds of component, including apps, flows and agents. Microsoft treats source control as the source of truth. Dataverse stores the solutions and the in-product deployment pipelines, and a CI/CD platform such as Azure DevOps can automate build, test and deployment. Layers, dependencies and upgrades are covered on Customization XML to solutions to pipelines.

What this page still needs

Written from Microsoft’s current Dataverse, Power Platform and Power Automate documentation. Not yet covered, and not guessed at: elastic tables, low-code plug-ins and Power Fx, environment variables and connection references in detail, capacity and storage, and the security model changes since 9.x. Because Dataverse changes continuously, everything above will need rechecking, and the date on this page shows when it last was.