MicromOne: Dataverse and Azure App Registrations

The older connection string looked like this:

AuthType=Office365;
Username=user@tenant.onmicrosoft.com;
Password=password;
Url=https://org.crm.dynamics.com;

Today, this approach is considered legacy and unsupported for modern secure environments.

The Recommended Alternative

The most practical replacement for unattended integrations is:

AuthType=ClientSecret

Example:

AuthType=ClientSecret;
Url=https://yourorg.crm.dynamics.com;
ClientId=YOUR-APP-ID;
ClientSecret=YOUR-SECRET;
TenantId=YOUR-TENANT-ID;

This authenticates through Microsoft Entra ID (Azure Active Directory) using an Azure App Registration.

The Important Detail Most Developers Miss

When configuring Dataverse integrations, developers often focus on:

Application Users
Security Roles
Dataverse permissions

However, the real identity actually comes from Azure.

The Dataverse Application User is simply a representation of the Azure App Registration inside Dataverse.

The key link is:

Application (Client) ID

This means:

Azure App Registration defines the identity
Dataverse defines the permissions

So Where Does the Application Name Come From?

This was exactly the issue I encountered during migration.

Inside Dataverse, you create:

An Application User
Assign Security Roles
Configure permissions

But the actual application identity — including the displayed application name — originates from the Azure App Registration.

In practice:

Create the App Registration in Azure
Copy the Application (Client) ID
Create an Application User in Dataverse
Paste the Client ID
Dataverse associates the Application User with the Azure App

At that point, the Azure App Registration becomes the authoritative identity source.

So if you are wondering whether you should “call the name” from:

Dataverse User + Permissions
or Azure App Registration

The correct answer is:

Use the Azure App Registration as the source of truth for the application identity.

Dataverse is only responsible for authorization and security role assignment.

Typical Modern Authentication Flow

Here is the modern setup flow most Dataverse integrations should follow:

1. Create Azure App Registration

Inside Microsoft Entra ID:

App Registrations
New Registration
Save:
- Client ID
- Tenant ID

2. Configure API Permissions

Add:

Dynamics CRM → user_impersonation

Then grant admin consent.

3. Create a Client Secret

Under:

Certificates & secrets

Generate and securely store the secret value.

4. Create Dataverse Application User

Inside Power Platform / Dynamics:

Security → Users → Application Users

Then:

Create New User
Select the Azure App
Assign Security Roles

Common Migration Mistakes

Using Personal Accounts for Integrations

Many old integrations depended on real user credentials.

Modern integrations should use dedicated Application Users instead.

Forgetting Dataverse Security Roles

Azure authentication succeeding does not automatically grant Dataverse access.

The Application User still requires proper Security Roles.

Confusing Authentication with Authorization

Azure authenticates the app.

Dataverse authorizes the app.

These are separate responsibilities.

Assuming the Dataverse User Owns the Identity

The identity is controlled by Azure App Registration.

Dataverse only maps permissions to that identity.

MicromOne

Pagine

Dataverse and Azure App Registrations