What Oleria discovers
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 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, 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:- 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.
- Client Secret Authentication. You register your own app in Microsoft Entra ID and give Oleria a client secret.
- Client Certificate Authentication. You register your own app and give Oleria a certificate and its private key.
1
Register an application
In the Microsoft Entra admin center, 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.2
Create a credential
- Client secret
- Client certificate
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.
3
Grant Microsoft Graph permissions
Select API permissions -> Add a permission -> Microsoft Graph -> Application permissions. Add these read-only permissions, then select Grant admin consent:
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.
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 first. After consent, Oleria reports that Dataverse refused the app. Add the app here, then select Authenticate again.1
Open application users
In the Power Platform admin center, open Manage -> Environments -> your environment -> Settings -> Users + permissions -> Application users.
2
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.
3
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.
Connect Microsoft Dynamics 365 to Oleria
1
Open the integration
Sign in to your Oleria workspace, go to Integrations, and select Microsoft Dynamics 365.
2
Complete the connection form
3
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.
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.
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.
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.AllGraph 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.