How do you grant and troubleshoot model-driven app access?
HOTSPOT
A company deploys a model-driven app to multiple departments.
The company requires the following app functionality:
Enable users to open the app.
Determine why users cannot access the app.
You need to configure app access.
Which actions should you perform? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
Community Insight
It tests the split between granting app access through security-role assignment and diagnosing denials with App Access Checker; the trap is picking a troubleshooting tool for the grant step or a role assignment for the diagnosis step.
This hotspot asks how to let users open a model-driven app deployed to multiple departments and how to diagnose access failures. The page establishes that users are granted access by assigning them a security role (app sharing), while access problems are diagnosed with the App Access Checker.
Assigning a security role as the way to investigate why a user cannot open the app, or running App Access Checker as the way to grant access. Roles grant permissions; App Access Checker only reports which role, business unit, or licensing condition is blocking the user.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Users can only open a model-driven app if they are assigned a security role that has the privileges the app requires, so granting access means adding the users (or their team) to an appropriate security role via the app's sharing settings. The second requirement, determining why users cannot access the app, maps exactly to the App Access Checker, which is the built-in Power Apps diagnostic for model-driven apps. The checker returns a report showing whether the user has a license, which security roles and business unit apply, and what specific privilege is missing, so it is the correct diagnosis action. These two selections cover the two stated requirements without overlap.Why Other Candidate Answers Are Wrong
Publishing or re-saving the app does not grant access, because model-driven app security is enforced by Dataverse security roles rather than by the app record itself. Enabling a license alone is insufficient: a licensed user with no matching role still receives an access-denied message, so licensing is only one of several checks. Adding the user to an environment security role in a different business unit also fails to help, since role scope is evaluated against the user's business unit, which is precisely what the App Access Checker reveals. Conversely, running the checker does not modify any permissions, so it cannot satisfy the requirement that users be able to open the app.Community Comment Notes
FabiolaRT pointed to the official Microsoft documentation for the App Access Checker with the link "https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/app-access-checker", which confirms that checker is the designated tool for resolving model-driven app access problems. Her comment contains no vote-selected answer, so the verdict here is derived from the Microsoft documentation rather than from any community consensus.Official Reference
Exam Strategy
Treat each hotspot row as its own requirement and match the verb: 'enable users to open' is a permission grant (security-role assignment through sharing), while 'determine why users cannot access' is a diagnostic. On the real exam, never let a troubleshooting tool appear in the grant slot or a permission change appear in the diagnosis slot.
Frequently Asked Questions
How do you let users open a model-driven app in Power Apps?
Assign the users or their team a Dataverse security role that has the privileges the app requires, typically through the app's sharing settings. A license alone does not grant access.
What does App Access Checker show for a model-driven app?
It reports whether the user is licensed, which security roles and business unit apply to them, and the specific missing privilege causing the access-denied error.