> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Microsoft Dynamics 365

> Connect a Microsoft Dynamics 365 (Dataverse) environment to Oleria to discover users, non-human identities, Copilot Studio agents, security roles, teams, record access, and audit and sign-in activity.

Connect Microsoft Dynamics 365 to Oleria to see who and what can reach your CRM data, and how. Oleria reads one Dataverse environment per connection, covering Dynamics 365 Sales, Customer Service, Field Service, and Marketing. It adds sign-in, MFA, and authentication-method data from Microsoft Graph. You can review over-privileged access and act on it from Oleria.

## What Oleria discovers

| Area | Detail |
| :- | :- |
| **Users** | Every user in the environment, including guests, Microsoft Support, and Delegated Admin users, which are marked as external. Each user has license, last-activity, and last-password-change details, MFA status, and registered authentication methods. Last activity is the user's last access to this environment from the Dataverse user-access audit; when the environment doesn't audit user access, it is the user's last Microsoft Entra sign-in. Single sign-on is always required, because Dynamics 365 accepts only Microsoft Entra ID sign-in. Users who hold System Administrator or System Customizer, or a Microsoft Entra administrator role, are flagged as administrators. |
| **Non-human identities** | Application users and their app-registration secrets, certificates, and owners. Also cloud flows and classic workflows (with the user they run as), webhooks and service endpoints, custom plug-in assemblies, managed identities, and secret environment variables. |
| **Credentials** | App-registration secrets and certificates, webhook and service-endpoint keys (never the key value), and the connection references that cloud flows use. |
| **AI agents** | Copilot Studio agents in the environment, including the Dynamics 365 first-party agents. Each agent has its owner, its published version, who can use it (the users and teams it's shared with, or the Microsoft Entra groups it's limited to), and the tools and knowledge sources it calls, with the connection reference each tool uses. |
| **Security roles** | Security roles, including business-unit copies, and column security profiles. Includes who holds each one, directly or through a team. Microsoft Entra Global, Power Platform, and Dynamics 365 Administrators are shown holding **System Administrator**, because they have it in every environment, even before they become users of it. |
| **Teams** | Owner, access, and Microsoft Entra group teams with their members, and each team's administrator. |
| **Resources and access** | The environment, its business-unit tree, every table a security role grants access to (read, create, update, delete, share, and the access depth), and records shared directly with a user or team, with each record's owner. Organization-wide privileges, such as bulk delete or acting on behalf of another user, appear on the environment and are flagged as privileged. |
| **Activity** | The Dataverse audit log (record, role, team, sharing, and audit-setting changes), user sign-ins to Dynamics 365, and service-principal sign-ins. |

## Prerequisites

* A Dynamics 365 or Power Apps environment with Dataverse in the commercial cloud, and its URL, for example `https://contoso.crm.dynamics.com`. You can find it in the [Power Platform admin center](https://admin.powerplatform.microsoft.com) under **Manage** -> **Environments** -> your environment -> **Environment URL**.
* A **Global Administrator** or **Privileged Role Administrator** to grant admin consent in Microsoft Entra ID.
* A **Power Platform Administrator** or **System Administrator** in the environment, to add the application user.
* A dedicated app registration for Oleria (or Oleria's own app with OAuth), not one shared with other tools, so its application user holds only the role you give Oleria and its sign-ins are Oleria's alone.
* Optional: **Microsoft Entra ID P1 or P2**, for sign-in activity and the MFA registration report. Without it, Oleria still syncs, and those fields show as unavailable.
* Optional: auditing turned on in the environment, for the audit log and for last-activity dates that reflect use of Dynamics 365 itself. In the [Power Platform admin center](https://admin.powerplatform.microsoft.com), go to **Manage** -> **Environments** -> your environment -> **Settings** -> **Audit and logs** -> **Audit settings**, and turn on **Start Auditing** and **Log access**. Record changes are audited only for tables that have auditing turned on.

## Choose an authentication method

The connection form offers three methods. Pick one:

1. **Authenticate via Microsoft (OAuth)**, the default. You grant admin consent to Oleria's Microsoft app. You don't need to register an app or manage a credential.
2. **Client Secret Authentication**. You register your own app in Microsoft Entra ID and give Oleria a client secret.
3. **Client Certificate Authentication**. You register your own app and give Oleria a certificate and its private key.

For either manual method, register the app first:

<Steps>
  <Step title="Register an application">
    In the [Microsoft Entra admin center](https://entra.microsoft.com), go to **App registrations** -> **New registration**. Name the app (for example, `Oleria Dynamics 365`) and select **Register**. On its **Overview** page, copy the **Application (client) ID** and **Directory (tenant) ID**.
  </Step>

  <Step title="Create a credential">
    <Tabs>
      <Tab title="Client secret">
        Select **Certificates & secrets** -> **Client secrets** -> **New client secret**, then copy the secret's **Value**. Azure shows it only once. Choose the longest expiry your policy allows, and update the integration in Oleria before the secret expires.
      </Tab>

      <Tab title="Client certificate">
        Upload the public certificate under **Certificates & secrets** -> **Certificates**. Combine the certificate and its unencrypted private key into one PEM file, then base64-encode the whole file. You paste that base64 string into Oleria's **Private Key** field. Choose the longest validity your policy allows, and update the integration in Oleria before the certificate expires.
      </Tab>
    </Tabs>
  </Step>

  <Step title="Grant Microsoft Graph permissions">
    Select **API permissions** -> **Add a permission** -> **Microsoft Graph** -> **Application permissions**. Add these read-only permissions, then select **Grant admin consent**:

    ```
    User.Read.All
    AuditLog.Read.All
    UserAuthenticationMethod.Read.All
    Application.Read.All
    RoleManagement.Read.Directory
    GroupMember.Read.All
    ```

    <Note>Graph permissions only enrich the data. If one is missing, Oleria still syncs the environment and shows the affected fields, such as MFA status or sign-in activity, as unavailable.</Note>
  </Step>
</Steps>

## Add the app as an application user

Dynamics 365 rejects every request from an app that isn't an application user in the environment, even with a valid token. Do this for every authentication method.

With OAuth, the app is Oleria's Microsoft 365 app, which requests only read-only Microsoft Graph permissions. What it can change in Dynamics 365 depends on the security role you assign below. It appears in your tenant only after you grant admin consent, so grant consent for it even if you've already connected another Oleria Microsoft integration, and note the app name Microsoft shows on the consent screen. Complete [Connect Microsoft Dynamics 365 to Oleria](#connect-microsoft-dynamics-365-to-oleria) first. After consent, Oleria reports that Dataverse refused the app. Add the app here, then select **Authenticate** again.

<Steps>
  <Step title="Open application users">
    In the [Power Platform admin center](https://admin.powerplatform.microsoft.com), open **Manage** -> **Environments** -> your environment -> **Settings** -> **Users + permissions** -> **Application users**.
  </Step>

  <Step title="Add the app">
    Select **New app user** -> **Add an app**, and choose the app. With OAuth, search for the app name from the consent screen. Otherwise, choose the app registration you created.
  </Step>

  <Step title="Assign a security role">
    Under **Security roles**, assign a role, then select **Create**:

    * **System Administrator** if you'll authorize Oleria to perform write actions (remediation).
    * For visibility only, a custom security role is enough, and Oleria then can't change anything in the environment. Create it in the root business unit with **Organization** read access on:
      * **Business Management:** Business Unit, Field Security Profile, Organization, Security Role, Team, User.
      * **Customization:** Agent, Agent component, Connection Reference, Entity, Environment Variable Definition, Managed Identity, Plug-in Assembly, Plug-in Type, Process, SDK Message Processing Step, Service Endpoint.
      * **Miscellaneous privileges:** View Audit History and View Audit Summary.
  </Step>
</Steps>

## Connect Microsoft Dynamics 365 to Oleria

<Steps>
  <Step title="Open the integration">
    Sign in to your Oleria workspace, go to **Integrations**, and select **Microsoft Dynamics 365**.
  </Step>

  <Step title="Complete the connection form">
    | Field | Notes |
    | :- | :- |
    | Authentication Method | **Authenticate via Microsoft (OAuth)** (default), **Client Secret Authentication**, or **Client Certificate Authentication**. |
    | Environment URL | Required. For example `https://contoso.crm.dynamics.com`. The bare organization name (`contoso`) works only for North America environments (`crm.dynamics.com`); for other regions, paste the full URL from the Power Platform admin center. You can't change it after you connect. |
    | Tenant Id | Client secret or certificate only. The **Directory (tenant) ID** of your app registration. You can't change it after you connect. |
    | Client Id | Client secret or certificate only. The **Application (client) ID** of your app registration. |
    | Client Secret | Client secret only. The secret value. |
    | Private Key | Client certificate only. The base64-encoded PEM file with the certificate and private key. |
    | I authorize Oleria to perform write actions in Microsoft Dynamics 365 | Optional, off by default. Select it only if you want remediation actions. When it's off, Oleria refuses every write action, including reverts of earlier actions. Either way, Oleria never requests Microsoft Graph write permissions. |
  </Step>

  <Step title="Authenticate">
    Select **Authenticate**. With OAuth, Microsoft asks an administrator to grant consent, then returns you to Oleria. Oleria checks access to the environment, and that the application user's security role can read users, teams, security roles, business units, and the organization, before it saves the connection.

    <Note>With OAuth, Oleria's app exists in your tenant only after consent. If the first attempt reports that Dataverse refused the app, add the app as an application user (see above), then select **Authenticate** again.</Note>
  </Step>
</Steps>

## Verify the integration

Confirm that the environment appears on the **Connected** tab of the **Integrations** page with a status of **Healthy**. After the first sync, review users, non-human identities, roles, and teams in your Oleria workspace.

## Remediation actions

Oleria can act on Dynamics 365 access when you select **I authorize Oleria to perform write actions in Microsoft Dynamics 365** on the connection form and the application user has the **System Administrator** role. You can revert an action that succeeded. If an action that makes several changes fails part-way, Oleria first undoes the changes it already made. If it can't restore something, the error message names it so you can fix it in Dynamics 365.

| Action | Reversible? |
| :- | :- |
| Add a user to a security role | Yes, by removing the role. |
| Remove a user from a security role | Yes, by adding the role back. Removes only a role assigned directly to the user. |
| Add a user to a team | Yes, by removing the user from the team. |
| Remove a user from a team | Yes, by adding the user back. |
| Disable a user | Yes, by enabling the user. |
| Enable a user | Yes, by disabling the user. |
| Disable a non-human identity: an application user, a cloud flow or classic workflow, or a plug-in or webhook step | Yes, by enabling it again. A flow that someone suspended or changed in the meantime isn't reactivated. |
| Add a Microsoft Entra user to the environment (needs the `User.Read.All` Graph permission). The user is added to the root business unit with no security role; add roles and teams separately. If the user is already in the environment, nothing changes; a disabled user stays disabled, so run **Enable a user**. | Yes, by disabling the user. Dynamics 365 never deletes users. |
| Create a team | Yes, by deleting the team, as long as no members or security roles were added to it since. An existing team with the same name in the root business unit is reused and isn't deleted on revert. |
| Revoke a user's or team's share of a record or an agent | Yes, by adding the revoked access back. Access granted since stays. |
| Revoke every share of an external (guest) user, or every guest share of a record or an agent | Yes, by adding each revoked access back. |

Oleria doesn't act on its own application user, on Microsoft Entra group teams or business-unit default teams (Dynamics 365 doesn't manage their membership), or on flows and steps from managed solutions.

## Known limitations

* **One environment per connection.** Connect each Dynamics 365 environment separately.
* **Commercial cloud only.** Environments in the US Government (GCC High, DoD) and China clouds can't be connected.
* **Disabling a synced user may not stick.** Dynamics 365 can re-enable a user on their next sign-in while they remain licensed and in the environment's security group. To block access, also disable the user in Microsoft Entra ID.
* **Not synced:** hierarchy security (manager and position), Power Platform connections, and canvas and model-driven app sharing.
* **Some data needs Microsoft Entra ID P1 or P2:** sign-in activity, the MFA registration report, and sign-in logs.
* **Last activity looks back up to 90 days**, or the environment's audit retention if shorter. An older last access shows as no recent activity.
* **Role-assignable groups that hold administrator roles** are expanded only if the app has the `GroupMember.Read.All` Graph permission. Otherwise, their members aren't shown as System Administrators, and the sync log names each group.
* **Revoking shares** removes only shares made directly to the user or team. Access through a team membership or a security role stays.
* **Removing a security role** removes only a role assigned directly to the user. A role held through a team stays; remove the user from the team instead. Microsoft Entra administrators keep System Administrator until their Entra role is removed.
* **AI agents** have no identity of their own in Dynamics 365: an agent acts as the person using it, or through the connections of its tools, which Oleria shows. An agent limited to a Microsoft Entra group links to that group's members when the group is also a team in the environment.
* **Adding a user** links an existing Microsoft Entra user to the environment; Dynamics 365 can't create the Entra account.
* **Audit activity** depends on auditing being turned on in the environment.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.