xrmverse
Documentation menu

Philosophy

← xrmverse documentation

The contract, not an imitation

The goal is not to "look like" Dataverse but to honour its contract: the same endpoints, the same SDK messages, the same system table names, the same solution format, the same error codes. Success means an existing client cannot tell the difference.

Three rules follow:

  1. Drop-in first. Every extension of our own uses the xrmverse_ prefix and never alters standard objects.
  2. Fail visibly. Anything that cannot be reproduced faithfully is rejected with an explicit error, never silently executed differently.
  3. Solution round-trip. A solution exported from xrmverse can still be imported into Dataverse.

One semantics

Everything goes through a single Core that implements IOrganizationService: the Web API, the CLI, MCP, solution import and the plugins themselves. There are no "privileged paths" that skip the pipeline or security. If a rule applies to one client, it applies to all of them.

Your data, your hardware

On-premise is not a secondary mode, it is the reason the project exists: data under your control, no mandatory cloud dependency, a one-command install, direct database access for backup and monitoring.

Self-sufficiency

XrmToolBox is Windows-only and pac does not cover everything (it cannot create tables or register plugins). That is why the xrmd CLI is complete and cross-platform: you can manage an environment from Windows, macOS or Linux with no other tool.

Built for AI agents

xrmverse ships with a built-in MCP server: agents (Copilot Studio, Claude and others) query data and manage the schema with the authenticated user's permissions, with no integration code.

Porting first, then innovation

For the UI the order is deliberate: first run existing Model-driven apps as they are, then let them move past Power Apps' limits with a completely different look.