Power Platform Scenario Questions and How to Answer Them

Scenario questions are the useful half of a Power Platform interview. They cannot be memorised, they reveal method, and each of the ones below has a confident wrong answer that a lot of candidates give.

Canvas apps

1. The app takes fifteen seconds to open. Where do you start?

Not by simplifying formulas. Start with the monitor tool and find where the time actually goes. It is usually the network: OnStart loading collections nobody needs on the first screen, whole tables retrieved when a filter would do, or sequential calls that could overlap.

The structural fixes are to move work out of OnStart and load on demand, filter at the source rather than in the app, use Concurrent for independent calls, and reduce control count per screen. Say "I would measure first" — it is the answer being listened for.

2. You need to update two thousand records. How?

Wrong answer: ForAll with a Patch inside. That issues one request per record, is slow, has no transaction, and fails partway leaving an unknown state.

Right answer: not in the app at all. Bulk work belongs in a flow, or in a job against the data source. If it must be initiated from the app, the app triggers a flow and reports on it. A candidate who reaches for ForAll at that volume has not watched one run.

3. A user navigates away mid-form and loses their input. Fix?

Hold the in-progress values in a variable or collection rather than relying on control state, since controls reset when a screen is unloaded. For genuine draft persistence across sessions, save a draft record with a draft status, or use SaveData for device-local persistence. Mention the trade: a draft record needs cleaning up.

4. Only signed-in users should see certain data. How?

Everyone is signed in — canvas apps require authentication. The real question is row-level access, and the answer is that it must be enforced by the data source. Dataverse security roles do this properly. Hiding controls or filtering in the app is not security: the underlying source is still readable by anyone who can reach it another way.

5. One form must handle create, edit and view. How?

A single form control with its mode set by a variable, using NewForm, EditForm and ViewForm. Three separate screens is the wrong answer — it triples the maintenance and guarantees the three drift apart.

6. It must work offline. What do you tell them?

Be honest about the limits. Canvas apps support limited offline scenarios through local collections persisted with SaveData and LoadData, with size constraints, and you own conflict resolution when connectivity returns. If the requirement is full offline with reliable sync, verify what the current platform capabilities support before promising it — and consider whether a different tool fits better.

7. How do you prevent duplicate records?

Check before insert, and enforce at the source. The check-before-insert in the app is a usability feature; it is not a guarantee, because two users can pass the check simultaneously. Dataverse alternate keys enforce uniqueness at the platform level, which is what actually prevents it. A candidate who offers only the app-side check has not thought about concurrency.

8. Different users must see different records. How?

Same as question four: the data source enforces it. In Dataverse, security roles with the appropriate access level and record ownership. Filtering in the app makes the interface tidy; it does not restrict access.

9. When do you use a collection?

When the same data is read repeatedly in a session and does not need to be current — reference data, lookup lists, an in-progress working set. Not as a general cache for everything, because a collection does not know the source changed, and not for large data, because it lives in the app.

10. Canvas or model-driven?

Decide by what changes most often. Data model, relationships and row-level access changing most means model-driven. Screen design, interaction and branding changing most means canvas. Security requirements phrased as "managers see only their team's records" are describing the Dataverse security model.

11. A user cannot see records they should be able to. Diagnose.

An excellent question because it has an order. Check the security role's read privilege and its access level for that table; check who owns the records; check whether a team owns them and whether the user is in that team; check the business unit; check whether a sharing grant was expected; and only then look at the app's own filters. The mistake is starting with the app.

12. A field must be mandatory only in some cases. How?

A business rule with a condition, scoped at entity level so it applies server-side as well as on the form. A form script is the fallback for logic a business rule genuinely cannot express — not the first choice, because it does not run on the server and is invisible to anyone reading the solution.

Common mistakes candidates make

• Answering security questions with UI filtering. The most common and most damaging error in this list.
• Reaching for ForAll and Patch for bulk work. It is the answer that scales worst.
• Optimising formulas before measuring. The network is nearly always the cost.
• Promising offline without qualifying it. The support is real and limited; overpromising is caught immediately.
• Starting diagnosis at the app. For access problems the answer is almost always in the data source.

Frequently asked questions

Should I say "I would measure first"?

Yes, when it is true. It is the answer that distinguishes people who have debugged production from people who have read optimisation lists — provided you can then say what you would measure and what you would expect to find.

What if I do not know?

Say so, then say how you would find out. "I would check the current documentation, because that limit has changed" is a stronger answer than a confidently wrong number, and interviewers know it.

How much Dataverse is expected?

Enough to explain the security model without notes. It is the topic that separates candidates most reliably, and it is where three of these twelve questions land.

Are these questions realistic?

They are the situations, not the wording. An interviewer will describe a broken thing and ask what you would do — which is why practising the reasoning is more useful than practising answers.

How to prepare

Take three of these, write the answer out, then write the follow-up question you would ask if you were the interviewer, and answer that too. The second layer is where interviews are actually won and lost, and it is the layer that memorising a list of answers does nothing for.