Microsoft Dynamics 365 Customer Experience Analyst : Share a model-driven app

A model-driven app in the Power Platform is a type of application built on top of Microsoft Dataverse that focuses on data structure and business processes rather than custom user interface design. Unlike canvas apps, where you design the UI freely, model-driven apps automatically generate responsive layouts based on the data model, forms, views, and relationships you configure in Dataverse. This makes them ideal for complex, data-centric solutions like sales, service, or compliance management, where consistency and scalability are crucial. They provide out-of-the-box features such as dashboards, charts, business process flows, and security roles, enabling organizations to deliver powerful, enterprise-grade applications with minimal custom coding while ensuring a consistent user experience across devices.

What Does “Sharing a Model-driven App” Mean?

When you share a model-driven app, you are giving other users or teams in your organization permission to access and use the app. Sharing doesn’t mean just providing a link; it requires ensuring the right security roles, permissions, and Dataverse access are in place so that users can open the app and interact with its data.

Steps to Share a Model-driven App

 1. Go to the Power Apps Maker Portal

  •  Navigate to (https://make.powerapps.com).
  •  Select the environment where your app is located.

 2. Locate Your App

  •  In the left navigation, select Apps.
  •  Find your model-driven app in the list.

 3. Share the App

  •  Select the app → click Share from the toolbar.
  •  The Share app panel opens.

 4. Assign Users or Teams

  • Search and select the users or Azure Active Directory (AAD) groups or teams you want to share the app with.
  • Add them to the sharing list.

 5. Provide Security Roles

  •  A user cannot access an app unless they have the correct security role(s).
  •  From the share panel, assign the appropriate Dataverse security roles.

   Example: Salesperson, Sales Manager, or a custom security role you’ve defined.

  •  You can also assign the App-specific role if created.

 6. Save and Share

  •  After assigning roles, click Share.
  •  Users will now see the app in their Dynamics 365 Apps list or directly via the link you provide.

 Important Points to Remember

 App Access vs. Data Access

 Sharing the app only gives visibility.

  • Users still need Dataverse table-level permissions (like Read, Write, Append) to work with the data inside the app.

 Teams vs. Users

  •  You can simplify access by assigning roles to a team instead of managing individual users.
  •  If a user joins that team, they automatically inherit permissions.

Custom Security Roles

Sometimes, out-of-the-box roles don’t fit. You can create custom roles with precise privileges.

Removing Access

  • To remove someone’s access, go back to the Share panel and remove the user/team, or unassign their security role.

 Benefits of Sharing Model-driven Apps

  • Controlled access – Only authorized users can use the app.
  • Collaboration – Teams can work together on business processes (e.g., managing sales opportunities).
  • Scalability – Easy to share with large groups using security roles or AAD groups.
  • Governance & Security – Ensures data is protected while enabling the right level of access.

Technical & Logical Reasons to Share a Model-driven App

1. Centralized Access Control
  • Instead of managing permissions user by user, you share the app with teams or Azure AD groups.
  • This ensures security and compliance by aligning access with organizational roles.
2. Security Role Enforcement
  • A model-driven app is tied to Dataverse security roles.
  • Sharing ensures users can only see the app if they have the correct privileges (Read/Write/Append/Delete) on relevant tables.
3. Data Governance
  • Sharing apps allows administrators to enforce data visibility rules (hierarchy security, field-level security, and team ownership).
  • Prevents accidental overexposure of sensitive data.
4. Reusability & Scalability
  • Apps are often designed for departments or regions (e.g., Sales, HR).
  • Instead of building separate apps, you can share one app with role-based access.
5. Consistency in Business Processes
  • By sharing the same app across users, organizations enforce standardized business process flows, forms, and rules.
  • Ensures data entry and workflows remain uniform.
6. Auditing & Compliance
  • Access sharing ensures audit trails can capture which users or teams accessed records.
  • Essential for regulated industries like oil & gas, finance, or healthcare.
Best Practices for Sharing a Model-driven App

1. Use Security Roles, Not Just Direct Sharing
  • Always share apps through security roles tied to Dataverse tables.
  • Avoid granting broad privileges; apply the principle of least privilege.
2. Prefer Team-based Sharing
  • Assign roles to owner teams or AAD groups instead of individual users.
  • Easier to maintain when people join/leave the organization.
3. Separate App Access from Data Access
  • Sharing an app does not equal full access to data.
  • Carefully configure table-level security (Read/Write/Append) and, if needed, field-level security.
4. Create Custom Security Roles for the App
  • Avoid over-reliance on out-of-the-box roles (like Salesperson or CSR).
  • Build custom roles tailored to the specific app’s tables, forms, and business needs.
5. Document Role-to-App Mapping
  • Maintain clear documentation of which roles map to which apps.
  • Helps admins avoid conflicts when multiple apps share tables.
6. Regularly Audit Access
  • Periodically review who has access to apps and underlying tables.
  • Use Dataverse auditing and Azure AD reporting to check for stale accounts.
7. Test with a “Least Privilege” User
  • Before rolling out, test the app using a user account with the lowest required role.
  • Ensures users see only what they need and nothing more.
Summary:
Sharing a model-driven app is not just about letting users open it — it’s about balancing collaboration, scalability, and security. Use roles, teams, and governance practices to ensure the right people get the right access, while protecting sensitive data and keeping administration simple.

Comments

Popular posts from this blog

Effective Strategies for Debugging Plugins in Dynamics CRM

Connecting the Dots: FetchXML and Web API Integration in Dataverse

Exploring the Differences: Managed vs. Unmanaged Solutions in Dynamics CRM/Dataverse