Contents
Introduction
Granting tenant consent and required permissions allows Tamarac to deliver a secure, automated, and fully integrated CRM experience through Microsoft Dynamics 365 (Dataverse) and Microsoft Entra ID (Azure AD).
This integration:
-
Uses OAuth 2.0, a secure, modern authentication protocol.
-
Eliminates dependency on human users.
-
Requires temporary elevated access only during onboarding, after which it uses the lowest-level permissions possible to complete the tasks.
-
Provides full transparency for security and compliance review.
This article provides a detailed explanation of Tamarac’s access requirements for integrating with Microsoft Dynamics 365 and Microsoft Entra ID.
Integration access requirements
Permission summary matrix
| Component | Permission | Required | Purpose |
|---|---|---|---|
| Global Admin |
Tenant Consent |
Yes (Temporary) | Approve application permissions |
| Entra ID |
Service Principal Creation |
Yes | Register Tamarac apps |
| Microsoft Graph | Directory.Read.All | Yes | Read directory data |
| Microsoft Graph | User.Read.All | Yes | Read user data |
| Microsoft Graph | Group.Read.All | Yes | Read group data |
| Dataverse | Application User | Yes | Enable CRM access |
| Dynamics 365 | Admin Role | Yes | Ongoing administration |
Why we require tenant‑level permissions
Tamarac uses secure, application‑based authentication to integrate with client environments. To make this integration possible, the onboarding process includes:
-
Registering Tamarac applications in Microsoft Entra ID.
-
Granting API permissions to access required Microsoft services.
-
Creating application identities within Dynamics 365 (Dataverse).
Tenant consent is required to authorize these Tamarac permissions at the organization level. This ensures Tamarac services can securely:
-
Read directory data (users, groups).
-
Authenticate via OAuth 2.0.
-
Interact with Dynamics 365 (Dataverse APIs).
Temporary vs. ongoing access requirements
The table below summarizes access requirements during and after onboarding.
| Access Type | During Onboarding | After Onboarding |
|---|---|---|
| Global Administrator |
Required (temporary) |
Not required |
| Tenant Consent | Required | Not required unless changes are needed |
| Service Principals | Created | Access persists |
| Application Permissions | Granted | Access persists |
| Dynamics Application Users | Created | Access persists |
| Dynamics Admin Role | Optional | Required |
Initial onboarding roles
During the onboarding process, your firm’s IT user or Microsoft Admin must assign the Microsoft Global Administrator role to our support user, CRM Org Creator. This elevated role is required because only a Global Administrator can:
-
Grant tenant‑wide application permissions.
-
Create and authorize service principals at the tenant level.
-
Approve OAuth 2.0 permission grants centrally.
As soon as the initial configuration is complete, the Global Administrator role can be removed immediately. Ongoing CRM administration does not require Global Administrator access.
Ongoing roles required
After onboarding is complete, we can transition from the temporary Global Administrator role to a permanent Dynamics 365 Administrator role for ongoing administration. Tamarac CRM runs under application identities rather than user accounts.
This reduces risk and follows the principle of using the lowest level of permissions possible to do the job.
Integration configuration components
During onboarding, the following components are configured to set up the integration:
-
Service principals, also referred to as enterprise applications.
-
API permissions, also referred to as application permissions.
-
OAuth 2.0 permission grants.
-
Dynamics 365 application users.
Service principals
Service principals, also referred to as enterprise applications, enable secure, app‑based authentication across Microsoft services. The Tamarac CRM integration uses the following service principals:
-
Microsoft Graph
-
Azure Active Directory for Entra ID
-
Dynamics CRM Online
-
Microsoft Power Apps
-
Tamarac services:
-
Tamarac Tenant Data Collection
-
Tamarac Integration Service
-
Tamarac Deployment Services
-
Tamarac Nightly Jobs
-
During the onboarding process, we retrieve or create service principals in Microsoft Entra ID at the tenant level. It then registers Tamarac backend services as trusted applications.
API permissions
API permissions, also referred to as application permissions, allow Tamarac services to operate in the background without requiring user login.
During the onboarding process, we grant these permissions via the following service principals:
-
Microsoft Graph
-
Azure Active Directory for Entra ID
-
Microsoft Dataverse
-
Microsoft Power Apps
The integration uses the following application-level permissions:
| Permission | Purpose | Access level |
|---|---|---|
| Directory.Read.All |
Read directory data |
Read-only |
| User.Read.All | Read user profiles | Read-only |
| Group.Read.All | Read group membership | Read-only |
OAuth 2.0 permission grants
Granting OAuth 2.0 permissions enables secure, token-based authentication, service-to-service communication, and encrypted and auditable access.
During onboarding, we create and approve permission grants for the following:
-
Microsoft Dataverse.
-
Microsoft Power Apps.
Dynamics 365 application users
During the onboarding process, we create the Application, Tamarac User in Dynamics 365.
Application users in Dynamics 365 support the following features:
-
Dynamics 365 mapping to the Azure AD service principal.
-
Tamarac services acting as a system user in Dynamics.
-
Fully automated and secure backend operations.
-
Avoiding reliance on user credentials.
Integration behavior after setup
How Tamarac services authenticate
Once the integration is enabled, Tamarac services authenticates users with the following methods:
-
OAuth 2.0 client credentials flow.
-
Azure AD service principals.
-
Application users in Dataverse.
Tamarac doesn’t store usernames or require specific sign-ins. All authentication works through secure certificate- or secret-based protocols.
What data Tamarac services can access
Once the integration is enabled, Tamarac services operate under controlled and minimal access so that no unnecessary access is granted, and permissions follow least-privilege principles. Tamarac limits access to what is required for CRM integration functionality.
The following table outlines what Tamarac services can access across data types:
| Data type | Access level |
|---|---|
| User Directory Data | Read-only |
| Group Membership | Read-only |
| Dynamics 365 (Dataverse) Data | Read/Write (as required for CRM functionality) |
Security concerns - FAQ
To review answers to common security questions, see Security concerns - frequently asked questions.