Microsoft Dataverse Security Cheat Sheet for App Makers

You built an amazing app, but can the wrong people see sensitive data? This cheat sheet covers the three core security concepts every Power Apps maker needs to understand to control who sees what data in their apps. If you're focused on building and showing data but haven't thought deeply about access control, start here.

Why this matters right now

Many new app makers share their apps and discover users either can't see any data (frustrating) or can see ALL the data including sensitive information they shouldn't access (dangerous). Dataverse security works differently than you might expect, and hiding a button or disabling a control doesn't actually secure your data. Real security happens at the data layer, not the UI layer.

The three security concepts you must understand

1. Security roles: Who can do what

What it is: Security roles define what actions users can perform (Create, Read, Write, Delete, Share, Assign) and at what scope (their own records, their business unit's records, or all records in the organization).

Why it matters: Even if users can open your app, they need the right security role to actually see and work with data. Security roles are cumulative—if a user has multiple roles, they get the most permissive access.

What to think about:

• Every user needs at least the Basic User role to access any Dataverse data
• System Administrator gives full access to everything—only assign when absolutely necessary
• For custom tables, predefined roles don't include permissions—you must create custom security roles
• Security roles don't work across environments—configure them in every environment where your app runs

Key actions:

• Create custom security roles that grant only the minimum permissions users need
• Test your app as a regular user, not as System Administrator
• Use the principle of least privilege—start restrictive and add permissions as needed

Learn more:

• Get started with security roles (Training module)
• Security roles in Dataverse
• Create or edit security roles

2. Column-level security: Protecting sensitive fields

What it is: Column-level security (also called field-level security) restricts access to specific columns within a table—like hiding salary data, social security numbers, or medical information from users who can still see the rest of the record.

Why it matters: Sometimes users need to see most of a record but shouldn't access certain sensitive columns. Table-level security is too broad; column-level security provides the granular control you need.

What to think about:

• Once enabled on a column, only System Administrators can see it unless you create a column security profile that grants access
• Secured columns show asterisks (********) to users without access
• You cannot secure lookup columns, primary name columns, or most system columns (like Created By)
• Column security applies organization-wide, not just in your app

Key actions:

• Enable column security in the column's Advanced Options in the Power Apps maker portal
• Create column security profiles that specify who can Create, Read, Update, or view unmasked data
• Assign these profiles to users or teams who need access to sensitive columns
• Always test with a non-admin account—admins bypass column security

Learn more:

• Column-level security
• Enable or disable security for a column

3. Business Unit hierarchy: Organizational boundaries

What it is: Business units create organizational structure and security boundaries in Dataverse. Every environment has one root business unit; you can create child business units to represent departments, regions, or teams. Each user belongs to exactly one business unit.

Why it matters: Business units work with security roles to determine data access scope. A security role set to "Business Unit" level means users only see records owned by their business unit. This enables departmental data isolation (Sales can't see Service department records).

What to think about:

• Most new apps don't need multiple business units—use security roles and teams first
• Business units add complexity; only use them when you truly need organizational data separation
• Users can only be in one business unit at a time
• When users create records, those records are owned by their business unit
• The Modernized Business Units feature (newer environments) allows users to access data across multiple business units more easily

When to use business units:

• Different departments need strict data isolation (Finance vs. HR vs. Sales)
• Different geographic regions need separate access (North America vs. Europe)
• Compliance requirements mandate data segmentation
• Complex organizational hierarchies require tiered access control

Key actions:

• Start simple—use a single business unit with security roles until you have a clear need for more
• If you must use multiple business units, document which users belong to which BU and why
• Understand whether your environment uses traditional or modernized business unit security
• Consider hierarchy security (manager access) as an alternative to creating many nested business units

Learn more:

• Security concepts in Dataverse
• Create or edit business units
• Modernized business units

Canvas apps vs model-driven apps: Critical differences

Canvas apps use two-tier security

How it works:

1. App-level sharing: You share the canvas app directly with users or Microsoft Entra (Azure AD) security groups
2. Data-level security: Users still need appropriate Dataverse security roles to access the data

What this means:

• Users can open your app but see errors or empty screens if they lack proper security roles
• When you share a canvas app, the sharing panel prompts you to also manage security roles—don't skip this step
• Use explicit connections (users authenticate with their own credentials) not implicit connections (everyone uses your credentials)

Critical point: If your canvas app connects to Dataverse, you must do BOTH—share the app AND assign security roles. One without the other won't work.

Model-driven apps use role-based security only

How it works:

• No separate app sharing—users access model-driven apps entirely through Dataverse security roles
• Security roles must grant privileges for the app itself (Model-driven App table) plus all tables used in the app

What this means:

• You must create or customize security roles before sharing a model-driven app
• For custom tables, predefined roles don't work—you must create custom security roles with appropriate privileges
• Users need to exist in the environment (not just Microsoft 365)
• No email invitations are sent—you must share the app link manually

Critical point: Model-driven app security is simpler but less flexible—everything is controlled by Dataverse security roles, and users can't access the app without proper role assignments.

Learn more:

• Share canvas apps
• Share model-driven apps
• Security planning for Power Apps

Security validation checklist

Before sharing any app

• Identify your users: Who needs access to this app and what data should they see?
• Create user groups: Divide users into groups with different data access needs (viewers vs. editors, departments, regions)
• Define data access levels: Should users see only their own records, their team's records, their department's records, or all records?
• Check for sensitive data: Identify columns with sensitive information that need column-level security
• Use security groups: Share with Microsoft Entra security groups, not 100+ individual users

For canvas apps specifically

• Share the app with users or security groups (User or Co-Owner permissions)
• Assign Dataverse security roles for every Dataverse table your app accesses
• Share other data sources (Excel files, SharePoint lists, SQL databases)
• Verify connection types: Use explicit connections (not implicit) for Dataverse and SQL Server
• Test with a regular user account: Don't test only as yourself if you're an admin

For model-driven apps specifically

• Create custom security roles with minimum required privileges for your app
• Grant privileges for custom tables: Predefined roles don't cover custom tables
• Configure privileges for the app itself: Users need read access to the Model-driven App table
• Set up column security profiles if using column-level security
• Consider form-level security: Restrict sensitive forms to specific security roles
• Define a fallback form: Set a default form for users without specific role assignments
• Test with actual user accounts: Use representative user accounts or the "Act as" feature
• Share the app link: Model-driven apps don't send automatic invitations

Common security mistakes to avoid

Mistakes that leave data exposed

Relying on UI-level security: Hiding controls, disabling buttons, or filtering data in Power Fx formulas does NOT secure your data. Users can inspect network traffic or modify apps. Always implement security at the data source level using Dataverse security roles and column-level security.

Using System Administrator for testing only: If you only test as System Administrator, your app will work perfectly for you but fail or expose data for end users. Always test with representative user accounts that have the actual security roles you'll assign to real users.

Forgetting to share data sources: Sharing a canvas app doesn't automatically share Excel files, SharePoint lists, or other connections. Users will get errors when they try to use the app. Share all underlying resources when sharing canvas apps.

Building in the default environment: The default environment is shared by all users in your tenant with minimal governance. Building apps with sensitive data here risks unauthorized access. Create dedicated environments with proper security boundaries.

Mistakes that break apps for users

Not assigning Dataverse security roles: Sharing a canvas app but forgetting to assign security roles means users can open the app but can't see any data—just errors or blank screens.

Using overly restrictive security roles: Creating security roles that are too restrictive means users can't complete their work. Start with the minimum permissions needed, then add permissions as users report access issues.

Not configuring custom table privileges: For model-driven apps with custom tables, predefined security roles don't include any privileges. Users won't be able to see or work with your custom table data.

Forgetting column security profiles: Enabling column-level security without creating and assigning column security profiles means only System Administrators can see those columns—everyone else sees asterisks.

Where to learn more

Official Microsoft documentation

Core security concepts:

• Security in Microsoft Dataverse
• Assign security roles to users
• Security and governance considerations

Best practices:

• Best security practices for Power Apps (Official Blog)
• Power Platform Security FAQs
• Control access to model-driven app forms

Excellent community resources

For understanding security roles:

• Introduction to Dataverse Security Roles by Benjamin Crowe (February 2025) — Most recent comprehensive intro for beginners
• Microsoft Dataverse security model intro by Alex (It Ain't Boring) — Visual breakdown with diagrams

For implementing column-level security:

• How To Enable Column Level Security In Dataverse by Matthew Devaney, Microsoft MVP — Step-by-step tutorial with screenshots
• 6 Easy Steps to Enable Column Level Security by Creospark — Beginner-friendly format

For business units and record-level security:

• Dataverse Record Level Security by Josh Cook, Microsoft MVP — Tutorial with real-world scenario
• Dataverse Modernized security model for Business Unit by Dynamics Chronicles MVP — Explains new features clearly

For video learners:

• PowerApps911 Tutorials by Shane Young, Microsoft MVP — Extensive YouTube channel with beginner-friendly videos on Power Apps security

For access teams and advanced topics:

• The Complete Dataverse Access Teams Setup Guide by Matthew Devaney — When multiple people need to collaborate on specific records

Quick reference: Security concepts summary

Remember: Start with security roles, add column-level security for sensitive data, and only implement business units when you have a clear organizational need for data isolation. Most apps only need security roles and maybe column-level security.

Your next steps

1. Audit your existing apps: Review apps you've already shared and verify users have appropriate security roles
2. Create a security plan: For your next app, identify user groups and required data access before building
3. Set up a test environment: Create a separate environment where you can safely test security configurations
4. Test as a regular user: Create or borrow a non-admin account to validate your security works correctly
5. Bookmark the documentation: Keep the official Microsoft documentation links handy for detailed guidance
6. Join the community: Follow Microsoft MVPs and community blogs to learn from real-world implementations

Security isn't scary—it's just about asking the right questions: Who needs this app? What data should they see? What actions should they perform? Answer those questions, configure the appropriate security roles and column security, and you'll build apps that are both functional and secure.