Ova

How do you revoke Access in Power Automate Dataverse?

Published in Dataverse Access Management 5 mins read

To revoke access for a user or team to a specific record in Power Automate Dataverse, you use the 'Perform an unbound action' within your flow, specifically selecting the RevokeAccess action. This method allows for precise control over shared access permissions.

Understanding Dataverse Unbound Actions for Access Management

Dataverse provides specific actions that are not tied to a particular record type but operate at a system level. These are known as "unbound actions." Access removal is a key example of such an unbound Dataverse action, much like sharing, which enables granular control over who can interact with individual records. By leveraging these actions, you can programmatically manage access rights directly within your Power Automate flows.

Step-by-Step Guide to Revoke Access in Power Automate

Revoking access involves configuring the 'Perform an unbound action' in your Power Automate flow to execute the RevokeAccess operation.

Prerequisites

Before you begin, ensure you have:

  • Access to a Power Automate environment.
  • An active Dataverse connection within your environment.
  • The necessary security role permissions in Dataverse to revoke access (typically, a System Customizer or a custom role with ActOnBehalfOf and prvRevokeAccess privileges on the target entity).

Building Your Flow to Revoke Access

Follow these steps to configure your Power Automate flow:

  1. Choose a Trigger:

    • Start by adding a trigger to your flow. This could be manual (e.g., "Manually trigger a flow"), a scheduled recurrence, or an event-driven trigger (e.g., "When a row is added, modified or deleted" from Dataverse).
  2. Add a Dataverse Action:

    • After your trigger, add a new step. Search for the "Microsoft Dataverse" connector.
  3. Select 'Perform an unbound action':

    • From the list of Dataverse actions, choose 'Perform an unbound action'. This action is crucial for executing system-level operations like access revocation.
  4. Configure the 'RevokeAccess' Action:

    • In the 'Perform an unbound action' step, you will need to specify the action name and its parameters.
    • Action Name: From the dropdown list, select RevokeAccess.
    • Target: This parameter specifies the record from which access is being revoked. You must provide an object that includes the logical name of the entity and the GUID of the specific record.
      • Example: To revoke access from an account record with a specific GUID, the value might look like this:
        {
          "id": "YOUR_ACCOUNT_RECORD_GUID",
          "logicalname": "account"
        }

        You can often retrieve the GUID using a previous 'Get a row by ID' Dataverse action.

    • Revokee: This parameter specifies the user or team whose access is being revoked. Similar to the Target, you provide an object with the logical name and GUID of the user or team.
      • Example for a user:
        {
          "id": "YOUR_USER_GUID",
          "logicalname": "systemuser"
        }
      • Example for a team:
        {
          "id": "YOUR_TEAM_GUID",
          "logicalname": "team"
        }

        You can often retrieve user or team GUIDs using Dataverse 'List rows' or 'Get a row by ID' actions.

Practical Example: Revoking a User's Access to a Specific Account

Imagine a scenario where a specific user should no longer have direct access to a particular account record after a certain event.

Flow Configuration Snippet

[Your Trigger] (e.g., Manually trigger a flow)

    ↓

Get Account Record (Dataverse - Get a row by ID)
    - Table name: Accounts
    - Row ID: [Dynamic content or hardcoded GUID of the account]

    ↓

Get User Record (Dataverse - Get a row by ID)
    - Table name: Users
    - Row ID: [Dynamic content or hardcoded GUID of the user]

    ↓

Perform an unbound action (Dataverse)
    - Action Name: RevokeAccess
    - Target:
        {
          "id": @{outputs('Get_Account_Record')?['body/accountid']},
          "logicalname": "account"
        }
    - Revokee:
        {
          "id": @{outputs('Get_User_Record')?['body/systemuserid']},
          "logicalname": "systemuser"
        }

RevokeAccess Action Parameters Summary

Parameter Description Expected Value (JSON Object)
Target The specific Dataverse record from which access is being revoked. { "id": "RecordGUID", "logicalname": "entitylogicalname" }
Revokee The user or team whose access is being revoked. { "id": "UserOrTeamGUID", "logicalname": "systemuser" or "team" }

Important Considerations for Access Revocation

When revoking access, keep the following points in mind:

  • Scope of Revocation: The RevokeAccess action primarily removes direct shared access that was explicitly granted to a user or team on a specific record. It does not affect access inherited through security roles, business unit membership, or hierarchical security.
  • Permissions: The service principal or user account under which the Power Automate flow connection runs must have the necessary privileges to RevokeAccess on the target entity. If the flow lacks these permissions, it will fail.
  • Inheritance: If a user has access to a parent record and access is inherited by child records, revoking direct access to a child record might not fully remove their ability to see it if they still have access through the parent.
  • Testing: Always test your access revocation flows thoroughly in a development or test environment before deploying to production. Verify that access is removed as expected and that no unintended side effects occur.
  • Error Handling: Implement robust error handling in your Power Automate flows to manage scenarios where access revocation might fail (e.g., record not found, permission issues).

Differentiating from Security Roles

It's crucial to understand that revoking access via an unbound action is distinct from managing access through Dataverse security roles. Security roles define a baseline level of access across an organization, business unit, or for specific entity types. The RevokeAccess action, however, targets specific direct shares on individual records, offering a more granular, ad-hoc control over permissions without altering a user's fundamental security role assignments.

For more detailed information on Dataverse security and Power Automate, refer to the official Microsoft Dataverse documentation and Power Automate documentation.