DQE One Roles and Permissions in Dynamics
The DQE One package for Dynamics 365 / Power Platform ships with three Dataverse security roles. Assign them based on how each user interacts with DQE.
Three roles, for three types of users
- DQE - User: everyday access for end users who use real-time validation (address, email, phone, name, B2B) on Account, Contact and Lead forms.
- DQE - Data administrator: configuration access to DataQ Settings and the country table, for the person who sets up and maintains DQE One.
- DQE - Unify Application User: non-interactive role for the application user used by the DQE Standalone (Unify) server to read, update, share and merge Account, Contact and Lead records.
Which role for which use case?
| I want to… | What I need |
|---|---|
| Install the DQE One managed solution | The Dataverse built-in System Administrator or System Customizer security role — not a DQE role. None of the three DQE roles include solution-import privileges. |
| Use real-time validation (address, email, phone, name, B2B) on Account, Contact or Lead forms | DQE - User |
| Configure DataQ Settings (licence, enabled products, API URL, Standalone URL) | DQE - Data administrator |
| Manage the country table | DQE - Data administrator |
| Create or edit field mappings | See Known limitation below — as shipped, neither DQE role alone is sufficient |
| Let the DQE Standalone (Unify) application user read, update, share and merge records | DQE - Unify Application User, assigned to the application user created in Package Setup §1.3 |
What each role unlocks
| Role | Grants access to… |
|---|---|
| DQE - User | Read access to DataQ Settings, the country table and field mappings. It does not grant any extra access to Account, Contact or Lead — real-time validation runs through Dataverse Custom APIs that don't require record-level privileges, but your own Dynamics security model still needs to let the user read and edit those records for the forms themselves to work. |
| DQE - Data administrator | Full (Create/Read/Write/Delete) access to DataQ Settings and the country table, plus read-only access to Account and Contact. No access to field mappings — see Known limitation below. |
| DQE - Unify Application User | Read/Write/Append/AppendTo/Share/Merge on Account, Contact and Lead, plus full access to the country table. Deliberately excludes Create and Delete on Account, Contact and Lead — the application user can update and merge existing records but cannot create or delete them. |
Known limitation: field mappings
The Package Setup article lists DQE - Data administrator as the role to use for field mappings. In the current package, this role in fact grants no privilege at all on the field-mapping entity used by the mapping screen, while DQE - User only has read access to it. In practice, a user holding only the standard DQE roles cannot create, edit or delete a field mapping today — saving one requires a user with broader Dataverse access, such as System Administrator or System Customizer. If you hit a permissions error while saving a field mapping, this is the cause; contact your DQE project manager if you need this addressed.
Azure AD app registration: do you need "user_impersonation"?
The DQE Standalone (Unify) application connects to your Dynamics environment through an Azure AD application user (see Package Setup §1.2–§1.3). Some organizations' security policies flag the user_impersonation delegated permission on the Dynamics CRM API as overly broad and refuse to grant it.
This permission is not required. Dataverse access for the application user is enforced entirely through its assigned security role — DQE - Unify Application User — not through Azure AD API permissions. An app registration with no Dynamics CRM API permission at all, only the default User.Read permission on Microsoft Graph that Azure assigns automatically, works correctly: the application user can run DQE processes without any permission error, provided it holds the DQE - Unify Application User role in the target environment.
If your organization's security policy blocks user_impersonation, you can skip it entirely when registering the Azure AD application in Package Setup §1.2 and rely solely on the Dataverse security role.
Related articles
Related to