Dynamics Community Forum Thread Details

Hello Sushma Patole,

This is a well-structured approach to managing Dynamics 365 security based on license type, and using the Graph API for automation is a smart move for efficiency and scalability. Here's a breakdown of the best way to achieve this with minimal maintenance:

Core Strategy: Leverage Azure AD Security Groups and Power Automate (or Azure Logic Apps) with Graph API

The most robust and maintainable solution involves these key components:

Azure AD Security Groups: Your IT team has already established these, which is excellent. These groups will be the source of truth for license-based membership.

Power Automate (or Azure Logic Apps): This will be the automation engine to read group members and interact with the Dynamics 365 Web API for role assignment. Power Automate is generally more user-friendly for this scenario.

Dynamics 365 Web API: This is the programmatic interface to interact with Dynamics 365 data, including assigning security roles to users.

Detailed Steps and Considerations:

1. Identify the Mapping:

Clearly define the mapping between your Azure AD security groups and the corresponding Dynamics 365 security roles. For example:
- "SG_License_FieldService" maps to the "Field Service - Dispatcher" and "Field Service - Resource" roles in D365.
- "SG_License_SalesEnterprise" maps to the "Salesperson" and potentially other sales-related roles in D365.

2. Create Power Automate Flows (or Azure Logic Apps):

You'll need at least two main flows:

Onboarding/New User Assignment Flow:
- Trigger: "When a user is added to a group" (Azure AD connector). Trigger this flow for each of your license-based security groups.
- Action 1: Get User Details (Graph API): Use the "HTTP" action with Azure AD authentication to call the Microsoft Graph API endpoint to retrieve details about the newly added user (e.g., their user principal name or Azure AD object ID).
- Action 2: Find User in Dynamics 365 (Dynamics 365 Connector): Use the "List records" action in the Dynamics 365 connector to search for the user in the systemusers entity based on their Azure AD information (e.g., azureactivedirectoryid equals the user's Azure AD object ID).
- Condition: Check if the user exists in Dynamics 365.
  - If Yes:
    - Action 3: Assign Security Roles (Dynamics 365 Connector): Use the "Perform an action" action with the following parameters:
      - Entity Name: systemusers
      - Record ID: The systemuserid of the user found in the previous step.
      - Action Name: GrantAccess
      - Target: An array of JSON objects representing the security roles to assign. You'll need the roleid of each target Dynamics 365 security role.
  - If No: You might want to log this event or have a separate process to handle users not yet in D365.

Offboarding/User Removal Flow:
- Trigger: "When a user is removed from a group" (Azure AD connector). Trigger this flow for each of your license-based security groups.
- Action 1: Get User Details (Graph API): Similar to the onboarding flow, get the details of the removed user.
- Action 2: Find User in Dynamics 365 (Dynamics 365 Connector): Search for the user in systemusers.
- Condition: Check if the user exists in Dynamics 365.
  - If Yes:
    - Action 3: Retrieve Assigned Roles (Dynamics 365 Connector): Use the "List records" action on the systemuserroles entity, filtering by the systemuserid of the removed user.
    - Action 4: Revoke Security Roles (Dynamics 365 Connector): Use the "Perform an action" action with:
      - Entity Name: systemusers
      - Record ID: The systemuserid of the user.
      - Action Name: RevokeAccess
      - Target: An array of JSON objects representing the specific Dynamics 365 security roles that were initially granted based on this license group. You'll need to store or determine these roles. A good approach is to only revoke the roles related to the specific license group the user was removed from.
      - [
      {
      "@odata.type": "Microsoft.Dynamics.CRM.role",
      "roleid": "YOUR_FIELD_SERVICE_DISPATCHER_ROLE_ID"
      },
      {
      "@odata.type": "Microsoft.Dynamics.CRM.role",
      "roleid": "YOUR_FIELD_SERVICE_RESOURCE_ROLE_ID"
      }
      - ]
  - If No: Log the event.

2. Authentication and Authorization:

Azure AD Connection: The Azure AD connector in Power Automate will handle authentication to read group members. You'll likely need to grant consent for the Power Automate service principal to read directory data.

Dynamics 365 Connection: The Dynamics 365 connector will handle authentication to interact with your D365 environment. Ensure the connection uses an account with sufficient privileges to assign and revoke security roles (ideally a dedicated service principal).

3. Minimal Maintenance Strategies:

Configuration over Code: Using Power Automate's visual interface minimizes the need for custom code, making maintenance easier for a wider range of administrators.

Centralized Group Management: Relying on Azure AD groups as the single source of truth for license assignment simplifies management for your IT team.

Clear Mapping: Maintain a clear and well-documented mapping between Azure AD groups and D365 roles.

Error Handling and Logging: Implement robust error handling in your Power Automate flows (e.g., using "Try-Catch" blocks) and log events (successes and failures) to monitor the automation and troubleshoot issues. Consider using Dataverse tables or Azure Monitor for logging.

Service Principal for D365 Connection: Using a dedicated service principal for the D365 connector instead of a specific user account reduces the risk of the automation breaking if a user's password changes or their account is disabled.

Modular Design: Break down your flows into smaller, manageable components. This makes it easier to update or troubleshoot specific parts.

4. Onboarding/Offboarding Considerations:

Onboarding: When a user is added to a license-based Azure AD group, the onboarding flow will automatically assign the corresponding D365 roles.

Offboarding: When a user is removed from a license-based Azure AD group, the offboarding flow will automatically revoke the D365 roles associated with that license.

Direct D365 Role Assignment: You might need to decide how to handle direct role assignments within D365. One approach is to only manage roles through the Azure AD group membership. Another is to allow additional direct assignments but ensure the automation doesn't interfere with them unintentionally.

Limitations and Considerations:

Complexity of Role Mapping: If your role mapping is very granular or involves complex logic beyond a direct group-to-role relationship, you might need more sophisticated logic in your Power Automate flows.

Timing of Synchronization: There might be a slight delay between a user being added to/removed from an Azure AD group and the Power Automate flow triggering and completing the role assignment/revocation.

Handling Multiple License Groups: If a user belongs to multiple license groups, your flows will need to handle assigning all the corresponding D365 roles.

Initial Setup Effort: While the ongoing maintenance is minimal, the initial setup of the Power Automate flows and ensuring correct authentication will require some effort.

In summary, using Azure AD security groups as your central management point and automating role assignment in Dynamics 365 with Power Automate and the Graph API is the most efficient and maintainable approach for your scenario. By carefully planning the mapping, building robust flows with error handling, and using a service principal for D365 interaction, you can significantly reduce manual effort and ensure consistent security role assignments based on license type.

If my answer was helpful, please click Like, and if it solved your problem, please mark it as verified to help other community members find more. If you have further questions, please feel free to contact me.

My response was crafted with AI assistance and tailored to provide detailed and actionable guidance for your Microsoft Dynamics 365 query.

Regards,

Daivat Vartak