Dataverse Table Ownership & Security Permissions

Dataverse Table Ownership & Security Permissions

Clear explanation of ownership types and permission scopes (organization vs user/team)

Overview
In Microsoft Dataverse every table has exactly one ownership type. Ownership determines whether row-level security can be applied and which permission scopes are available in security roles.

1. Organization‑Owned Tables

Records are owned by the organization, not by users or teams. Row-level scopes (User / BU / Parent:Child BU) are not available.

Available permission scopes in security roles:
  • None - no user can perform the action
  • Organization - every user with the privilege can act on all records
Typical use: global configuration, metadata, reference lists or settings where everyone can read or manage at org-level.

2. User or Team‑Owned Tables

Each record has an explicit owner (a user or a team). This enables row-level security with multiple scopes available to security roles.

Available scopes for privileges (applies to Create/Read/Write/Delete/Append/AppendTo/Assign/Share):
  • None - no access
  • User - only records the user owns (created or assigned)
  • Business Unit - records owned by anyone in the same BU
  • Parent:Child Business Units - records owned in the user’s BU and all child BUs
  • Organization - all records across the environment
Typical use: operational data where ownership, teams, and BU boundaries matter (projects, cases, opportunities).

Scope-by-scope examples

User: If Read = User, a user sees only records they own.
Example: Sunil creates a record → only Sunil can view it.

Business Unit: If Read = Business Unit, all users in that BU can view records owned by any BU member.
Example: BU1 has 5 users - they can see each other's records.

Parent:Child BU: If Read = Parent:Child BU, users in a parent BU can see records in their BU and child BUs.
Example: BU1 (parent) sees BU1A & BU1B records.

Organization: If Read = Organization, all users can view all records.

None: If Read = None, the user cannot see records (even their own).

Quick Summary

Ownership Type Available Scopes Notes
Organization‑owned None / Organization Use for global reference data and settings. No row-level security.
User/Team‑owned None / User / BU / Parent:Child BU / Organization Use for operational data where ownership & BU boundaries matter.

Why it matters: Ownership decides which permission scopes you can use and whether row-level security is possible. Choose ownership carefully during design because changing it later is complex.

Comments

Post a Comment

Popular posts from this blog

Part 1: Creating Code Apps in Power Apps - A step-by-step guide (with real errors I faced & how I fixed them)

Image
Intro In this post I’ll walk you through how I set up a code-based app for Power Apps (React/Vite front-end + Power Platform CLI for packaging/deployment), the exact errors I ran into, and how I solved them. If you want a hands-on, copy-paste able guide that covers Node versions, pac auth, environment issues, and packaging tips, this is for you. Prerequisites Microsoft 365 account with access to a Power Platform environment Node.js ( 20.19+  recommended LTS) VS Code Install power platform tools extension in VS Code. Steps: Step 1 : Open Visual Studio Code and launch the integrated terminal. Step 2: In the terminal, run the following commands one by one.   mkdir D:\CodeApps - Force cd D:\CodeApps npm create vite @latest myfirstapp -- -- template react - ts cd D:\CodeApps\myfirstapp npm install Initially, I ran the command: npm create vite@latest MyFirstApp -- --template react-ts This gave the error: Invalid package.json name The issue was caused because package...
Read more

Calling Microsoft Graph API from Power Automate Using Azure App Services – Step-by-Step Guide

Image
Step 1: You should have an Azure subscription, or if you have access to the Microsoft Entra Admin Center, you can create an app from there. This app can then be used in Power Automate to connect to Microsoft Graph API. Step 2: Click on "New registration" , provide a name for your app, assign the required API permissions (such as Microsoft Graph permissions), and then click "Register" to complete the app registration process. Step 3: After registration, you'll be redirected to the app's overview page. From there, navigate to the API permissions tab and click "Add a permission" to assign the necessary Microsoft Graph API permissions. Step 4: Select Microsoft Graph as the API, and based on your requirements, choose the appropriate permissions. In my case, I selected Application permissions , which do not require user sign-in and are suitable for background services or automation. Step 5: Select the required Microsoft Graph API permissions. Yo...
Read more

Step-by-Step Guide: Power Automate Custom Connector Using Graph API from Azure App Service

Image
Step 1: Open Power Automate, navigate to the Custom Connectors tab, and select Create from blank as shown in the image below. custom connector(click image for better resolution) Step 2: In the General tab, upload an icon (less than 1MB), add a description, select the correct scheme (in my case, HTTPS ), and provide the host name. For example, if your API URL is https://graph.microsoft.com/v1.0/users/{email} , the host name will be the highlighted part — graph.microsoft.com . Step 3: Go to the Security tab. Here, you need to select the authentication method. Choose OAuth 2.0 as the authentication type, as shown in the image below. Step 4: Select the Identity Provider as Azure Active Directory . Check the box Enable Service Principal Support . This option allows you to create a connection using a Client ID and Client Secret instead of using the user's own authentication. Next, provide the Client ID , Client Secret , Tenant ID , and other required details as shown in t...
Read more