Converting Dynamics 365 Security Roles to Read-Only with PowerShell

 In Dynamics 365 / Dataverse, security roles often contain unintended modification privileges (Create, Write, Delete, etc.) even when they are meant to be read-only. Manually correcting them is time-consuming and error-prone — especially in environments with many custom entities.

This post shows how to safely convert existing roles into read-only roles using PowerShell.

---

The Problem

Roles labeled as “Read Only” still had privileges such as:

• Create

• Write

• Delete

• Append

• AppendTo

• Assign

• Share

The goal was to remove modification privileges while preserving:

• All Read privileges

• System-level privileges

• App and workflow functionality

---

The Solution

Using the Microsoft.Xrm.Data.PowerShell module:

1. Connect via Client Secret authentication

2. Retrieve the role

3. Fetch associated privileges

4. Remove only modification privileges

5. Leave system and read privileges intact

Import-Module Microsoft.Xrm.Data.PowerShell

$crmUrl = "https://yourorg.crm.dynamics.com"

$clientId = ""

$clientSecret = ""

$tenantId = ""

$conn = Get-CrmConnection -ConnectionString "

AuthType=ClientSecret;

Url=$crmUrl;

ClientId=$clientId;

ClientSecret=$clientSecret;

TenantId=$tenantId"

$rolesToFix = @(

    "AdvancedTemp - Read Only",

    "StandardTemp - Read Only"

)

# Only remove modification privileges

$removePattern = "^(prvCreate|prvWrite|prvDelete|prvAppend$|prvAppendTo|prvAssign|prvShare)"

foreach ($roleName in $rolesToFix) {

    $role = Get-CrmRecords `

        -conn $conn `

        -EntityLogicalName role `

        -FilterAttribute name `

        -FilterOperator eq `

        -FilterValue $roleName `

        -Fields roleid

    if ($role.CrmRecords.Count -eq 0) { continue }

    $roleId = $role.CrmRecords[0].roleid

    $fetch = @"

<fetch>

  <entity name='roleprivileges'>

    <filter>

      <condition attribute='roleid' operator='eq' value='$roleId' />

    </filter>

    <link-entity name='privilege'

                 from='privilegeid'

                 to='privilegeid'

                 alias='p'>

      <attribute name='privilegeid'/>

      <attribute name='name'/>

    </link-entity>

  </entity>

</fetch>

"@

    $privileges = Get-CrmRecordsByFetch -conn $conn -Fetch $fetch

    foreach ($priv in $privileges.CrmRecords) {

        $privId = $priv."p.privilegeid"

        $privName = $priv."p.name"

        if (-not $privId -or -not $privName) { continue }

        if ($privName -match $removePattern) {

            Remove-CrmRecordAssociation `

                -conn $conn `

                -EntityLogicalName1 role `

                -Id1 ([Guid]$roleId) `

                -EntityLogicalName2 privilege `

                -Id2 ([Guid]$privId) `

                -RelationshipName roleprivileges_association

        }

    }

}

Result

This script:

• Removes all modification privileges

• Preserves read and system access

• Prevents app or workflow breakage

• Automates role cleanup at scale

PowerShell provides a reliable and repeatable way to enforce true read-only security roles in Dynamics 365.

Impact of Dataverse Multiplexing on licenses

 impact of Dataverse Multiplexing on licenses, especially when customers log into the Portal to access data from Dynamics 365 CRM, and its impact on licensing requirements.

Scenario: Customers(external users) Accessing Data via Portal

In this scenario, your customers log into the Portal, which retrieves and displays data from Dynamics 365 CRM. This data access is managed through a service account that connects the portal to Dataverse.

Impact on Licensing

1. Service Account and Multiplexing: The service account acts as a single connection point to Dataverse, multiplexing multiple customer requests through one account. While this simplifies connection management, it does not change the underlying licensing requirements.
2. Customer Licensing: Each customer accessing data from Dynamics 365 CRM through the Portal must have the appropriate license. Using a service account to handle these connections does not reduce the number of required licenses.
3. Compliance: According to Microsoft’s licensing policies, each individual who accesses CRM data must be properly licensed. Therefore, you must ensure that every customer using the Portal has the necessary licenses, despite the service account managing the connection.

Conclusion

While Dataverse Multiplexing using a service account offers efficiency, it’s essential to remember that it doesn’t change licensing requirements. Every customer accessing Dynamics 365 CRM data via the Portal must have a valid license to ensure compliance with Microsoft’s terms.

I hope this clarifies the licensing implications of Dataverse Multiplexing in the context of customers accessing CRM data through the Carlisle Connect Portal. If you have any questions or need further clarification.

In the current context of the portal, Assume that User 4 is a Customer(External User), User 3 is a Service Account, Manually Forward Email is the external(Cache DB ), and Pooling Hardware/Software will be the API to access Dataverse