Proposal: Generate strongly-typed Dataverse entity models compatible with Xrm.WebApi

[Re-David-1992]

Hi 👋

First of all, thank you for building and maintaining DataverseDevTools;

it’s been extremely useful for improving developer productivity when working with Model Driven App web resources and TypeScript.

While using the extension I noticed that it already provides strong typing for form context, attributes, controls, and option sets, which is fantastic. However, when interacting with Xrm.WebApi, developers still have to rely heavily on:

• string literals for entity logical names
• string literals for attribute names
• untyped any payloads for create/update operations

Example today:

await Xrm.WebApi.createRecord("account", {
    name: "Contoso Ltd"
});

Although the form side is strongly typed, the moment we cross into WebApi operations, we lose most compile time safety.

Proposal

Introduce an optional code generator for strongly typed Dataverse entity models that work directly with Xrm.WebApi.

The goal is not to replace the native Xrm APIs, but to provide a typed model layer that reduces string literals and improves maintainability.

Example generated entity model:

export class Account extends Entity {
    public accountid?: string;
    public name?: string;
    public telephone1?: string;
    public primarycontactid?: string;

    public static readonly entityLogicalName = "account";
}

Usage with native APIs:

const account = new Account();
account.name = "Contoso Ltd";

await Xrm.WebApi.createRecord(
    Account.entityLogicalName,
    account.toRecord()
);

Retrieve example:

const raw = await Xrm.WebApi.retrieveRecord(
    Account.entityLogicalName,
    id,
    "?$select=name"
);


const account = Account.fromRecord(raw);

Design approach

The idea is to introduce a base Entity class that provides shared mapping logic.

Example responsibilities of the base class:

• toRecord() → converts the entity instance into a WebApi payload
• fromRecord() → hydrates the entity from a WebApi response

Each generated entity class would provide metadata such as:

• entity logical name
• attribute logical names
• attribute types (lookup, string, number, etc.)

This keeps the entity model:

• DRY
• operation agnostic
• compatible with native Xrm.WebApi

Benefits

• reduces string literals in WebApi calls
• improves compile time safety
• provides a canonical entity representation
• keeps compatibility with @types/xrm
• similar developer experience to early-bound entities in C#, but idiomatic to TypeScript

Important notes

The intent would not be to build a full ORM or abstraction over Xrm.WebApi.

The entity models would simply provide:

• a typed entity structure
• mapping helpers (toRecord, fromRecord)
• logical name constants

All WebApi calls would still use the native Xrm APIs.

Potential scope for a first implementation

• base Entity class
• entity model generation per Dataverse table
• attribute metadata generation
• toRecord() / fromRecord() helpers
• reuse of existing option set enum generation

Future improvements could include things like typed request builders for Xrm.WebApi.online.execute, but that would be outside the initial scope.

Question for maintainers

Before investing time into a PR, I wanted to ask:

• Does this approach align with the goals of the project?
• Would entity model generation be considered in scope for the extension?
• Are there any architectural constraints I should be aware of before prototyping?

Happy to share a prototype or discuss alternative approaches if this direction seems useful.

Thanks again for the great tool!