Power Platform Developer Interview: Debugging Apps, Dataverse, and Solution Deployment

A Power Platform developer interview can be deceptively simple: “The app works for its maker, but a colleague sees an empty list. What would you do?” The weak answer edits a formula or gives the colleague administrator access. The stronger answer separates query behavior, identity and Dataverse permission, connection state, and deployed solution version. Each has a different proof.

This guide uses an original work-sample case, not a claim about Microsoft's or any employer's interview format. Microsoft's Live Monitor guidance supports user-specific diagnosis; its Dataverse security concepts and solution guidance establish separate runtime and deployment boundaries.

Quick answer: reproduce as the affected user before changing the app

Ask for the exact screen, user, environment, app version, data source, and expected record. Reproduce with that user's authorized access, ideally in a test environment. Use Live Monitor and Trace to compare the request and result against a working session. If the query is not delegated, the user may see an incomplete subset even though a small maker test looks fine. If the query is valid but access is denied, inspect the user's Dataverse role and record ownership or sharing. If the app cannot connect, inspect connection and environment configuration. Only then examine solution layers and the release that placed this version in the target environment.

This is not a checklist to recite without evidence. Each branch needs an observation that could make it false. A maker's screenshot is not evidence about the affected user's permissions; a successful solution import is not evidence that every runtime dependency or connection works. In an interview, say what you would inspect before proposing a repair and what negative test prevents an over-permissive fix.

Original case: the maker sees every account, the user sees none

Practice fixture, not a reported interview prompt. A canvas app lists account records and lets a sales user choose one. The maker sees expected accounts in the development environment. After a solution is imported to test, a colleague opens the app but sees no accounts. The colleague reports that a flow-driven “Create follow-up” button also fails. The interviewer asks for your first five minutes of diagnosis and your release decision.

Start by narrowing the symptom. Does the colleague see an empty list, an explicit authorization error, a connection prompt, or a spinner? Does the record exist in the target Dataverse environment? Does the maker see it in test, not just in development? Does the colleague have the app shared with them but lack data access? These distinctions matter because Power Platform has separate access surfaces for environment/app resources and Dataverse data. Microsoft's security-role documentation explicitly distinguishes making apps from having privileges on Dataverse tables.

Create a tiny test matrix rather than modifying production:

Observation in the target environment	Leading hypothesis	Next bounded check
Maker sees record; colleague gets access error	Dataverse privilege or access depth	Check role, table Read privilege, record owner/team, and sharing for that identity.
Both see only early records in a large table	Nondelegable query	Inspect delegation warning and Live Monitor query; test a record beyond the local limit.
App loads but flow action fails	Connection reference or flow permission	Inspect the bound connection, run history, and identity used by the flow.
Old UI persists after import	Solution layer/version	Inspect top layer, active version, and publish state before importing again.

An empty list alone does not tell you which row applies. Ask the user for a non-sensitive example record identifier and compare the actual requests. If the user is in another business unit, the same security role name may still confer a different effective record scope. If a team owns the record, inspect team membership. Microsoft's Dataverse security overview describes privileges such as Read, Write, and Append, combined with access levels, not a single “can use app” switch.

Debug the canvas app without mistaking a query limit for missing data

Delegation means a filter or computation is pushed to the data source rather than performed only over a limited local result set. Microsoft's delegation documentation explains why nondelegable formulas can appear correct on a small dataset but omit records at scale. Do not quote one universal row limit without checking current app settings and connector behavior. In a scenario, identify the formula and connector, then prove whether the server receives the intended filter.

Imagine the gallery filters accounts by a text expression and then sorts by a derived client-side value. A colleague searches for an account known to exist but outside the first locally retrieved slice. A maker can misdiagnose this as a permission issue because the result is empty. Test a known identifier with a delegable equality filter and inspect the network query in Live Monitor. If that record appears under the simple filter but not the original expression, you have evidence for query semantics. If it never appears and Monitor shows an access error, investigate authorization instead.

Live Monitor is evidence, not a magic fix. Microsoft's Trace and Live Monitor guide describes observing actions and results, including differences between users or environments. In an answer, name the action you would reproduce, the request/result you expect, and what you would redact before sharing logs. Avoid exposing user data, tokens, or connector secrets in an interview artifact. Then test the corrected formula against a record near the beginning and another known to be outside the prior local slice.

Dataverse authorization is about the operation and the record

For the colleague's account list, identify the exact table and operation: Read. For creating a follow-up, the relevant privileges may differ: creating the follow-up and associating it with an account are not the same operation. Microsoft's security concepts describe privileges including Create, Read, Write, Delete, Append, AppendTo, Assign, and Share. Ask which table each applies to and what access level is needed for the actual record owner. “Give Basic User” may be insufficient or excessive depending on the intended data scope.

The test should include a positive and a negative user. The positive user must see only the allowed accounts and complete the authorized flow. The negative user must still be unable to see an account outside their intended scope. This matters because a quick demonstration under System Administrator can make a broken model look fixed while silently widening access. If a user is meant to access a team-owned record, verify team membership and the effective role assignment rather than assuming a direct owner match.

When answering aloud, distinguish app sharing from data authorization. Sharing gives someone a route into the app; it does not guarantee the underlying data query or flow can run under their identity. Note the environment, affected identity, table, record and operation in your evidence. Then ask who owns security-policy approval. A developer may recommend a narrow role change, but should not unilaterally broaden tenant data access to close a ticket.

Flow and connection failures need a different owner

The failed button may be a cloud flow invocation, not a gallery query. Check whether the app is calling the flow at all, whether run history records the attempt, which connection reference is bound in the target environment, and whose identity the flow uses. An import may bring the flow definition while target-specific connection information still needs to be supplied. Microsoft's environment-variable documentation explains that values for external references belong in the target environment; deployment settings guidance explains how connection references and environment variables support automated deployment.

Do not solve a missing connection by embedding an administrator credential in a formula or by assuming the source environment's connection carries over. Confirm the flow's intended permission model and use approved service or user connections. If the flow ran and failed on a downstream API, preserve the run identifier and sanitized error. If it never ran, inspect the app binding and invocation path. Include a test for the specific colleague, since the maker may have a working personal connection that the deployed user does not.

Managed solutions and layers: why “import succeeded” is not the end

Microsoft's solution concepts distinguish unmanaged development artifacts from managed deployment artifacts. Its solution-layer guide explains that component behavior follows layered definitions, with the top layer relevant to what runs. A target environment can therefore have an active unmanaged customization or later layer that changes the result you expected from the newly imported managed package.

In the case, suppose the import report is green but a test user still sees an old label and the flow points to the wrong endpoint. Ask for the component's layer view, the package version, import mode, dependency report, target environment variables, and connection references. Check whether the layer containing your fix is actually active. Avoid repeatedly importing the same package to “make it stick”; that can complicate diagnosis while leaving the real top-layer issue untouched.

For a safe release decision, define acceptance before the import: colleague can see one allowed account, cannot see a forbidden one, can create a follow-up, and the flow reaches the intended test endpoint. Capture the exact version and configuration tested. If the old layer remains active or the required connection is missing, hold the rollout. If a production import later fails, rollback may involve more than reversing a single file; reason about data changes, dependent components, and the current layer stack before choosing a path.

Interview answers that reveal judgment

The interviewer may ask, “Would you fix the formula or add a role?” Reply conditionally: “I will decide after comparing Live Monitor output for both users and checking the stored account's ownership. If the server query is truncated by nondelegable logic, I will make the filter delegable and test a record beyond the previous slice. If access is denied, I will propose the minimum privilege and access depth, then prove that restricted records remain hidden.” This is an answer with a falsifiable branch, not indecision.

Another prompt: “The managed solution imported, but the app is still wrong.” Explain that import status proves packaging operations, not the runtime component selected by solution layers. Name the top-layer inspection and target-specific configuration, then choose a repeatable rollback or repair with an owner. If the interviewer asks for a universal command or exact UI location, acknowledge that tenant and release versions vary; describe the evidence required, then verify the current documentation or environment.

Final takeaway

Power Platform developer interviews reward separation of concerns. Reproduce as the affected user, observe the query, evaluate Dataverse access, inspect the connection, and then verify the deployed solution layer. Fix the boundary the evidence identifies, and retain a negative access test.

Sources and Further Reading

• Microsoft: Diagnose canvas apps with Trace and Live Monitor
• Microsoft: Delegation in canvas apps
• Microsoft: Dataverse security concepts
• Microsoft: Dataverse security roles
• Microsoft: Solution concepts
• Microsoft: Solution layers
• Microsoft: Environment variables
• Microsoft: Deployment settings for connection references and environment variables

Research note: Checked September 23, 2026. The scenarios and answer branches are original exercises, not employer-reported questions. Behavior depends on the connector, environment, solution version, and user permissions.