Most Power Platform labs teach you to click. This one asks a harder question at every step: of the seven things that could satisfy this requirement, why is this the right one?
You will build a small support ticket solution containing five distinct kinds of business logic, and by the end you should be able to look at a requirement and name the component that fits it, along with where that component executes, what can bypass it, and when it will let you down.
What you will build
A support team needs to track internal tickets through a lifecycle of New, In Progress, and Resolved. Each ticket accumulates updates. The solution has to:
- refuse to save a resolved ticket with no resolution notes
- guide agents through the expected process
- count the updates related to each ticket
- show how many days a ticket has been open
The pieces you will build, and the shape of problem each one solves:
| Component | Its job here |
|---|---|
| Dataverse tables | The authoritative records and the relationship between them |
| Model-driven app | The interface, generated from that data model |
| Business Rule | Immediate conditional validation while a person edits |
| Business Process Flow | Visible, repeatable guidance through stages |
| Rollup column | An aggregate over related rows |
| Formula column | A derived value from the current row |
The architecture in one picture:
Model-driven app
forms | views | navigation | process bar
│ reads and writes
Dataverse
Support Ticket 1 ───────< N Ticket Update
Ticket Status Update Details
Resolution Notes Support Ticket (lookup)
Formula: Ticket Age
Rollup: Update Count
│
Business Rule ── immediate form behaviour
The decision framework
This table is the lab’s actual subject. Everything you build is an instance of one of these rows.
| What the requirement says | Component | Mental model |
|---|---|---|
| Change form behaviour or validate entry | Business Rule | Enforce near the point of entry |
| Guide a person through stages | Business Process Flow | Guide the human process |
| Calculate from columns on the same row | Formula column | Derive |
| Aggregate related child rows | Rollup column | Summarise a relationship |
| React to events, orchestrate systems | Power Automate | Automate |
| Generate, classify, or summarise language | Prompt | Reason probabilistically |
| Enforce an invariant across every write path | Server-side validation | Protect authoritative state |
The discipline underneath it: start with the data model and the business outcome, then select the smallest component whose execution timing and enforcement boundary match the requirement. Those two properties decide almost every question in this lab.
What not to start with
Four reflexes that cost teams real time, and when each becomes right:
Do not start with a canvas app. This scenario is structured data, relationships, forms, views, security, and process stages, all of which a model-driven app generates from metadata. Canvas becomes correct when a validated requirement demands tailored interaction, device-specific work, or a composite experience the generated surface cannot serve.
Do not start with Power Automate for form validation. A cloud flow runs after an event. It cannot make a field required while someone is typing. Automate becomes correct when work must happen after a trigger: notification, approval, cross-system orchestration, scheduled jobs.
Do not start with a prompt. Required-field enforcement is deterministic and binary; a probabilistic answer adds cost and uncertainty without adding judgment. Prompts become correct for summarisation, extraction, classification, and drafting, once the deterministic controls exist.
Do not start with code. JavaScript and plug-ins are stronger and more expensive surfaces than a first pass needs. Server-side extensibility becomes correct when an invariant must hold across forms, APIs, imports, integrations, and custom clients. Which, as module 3 shows, is a real requirement this lab deliberately does not satisfy.
Before you begin
You need a Power Platform environment with Dataverse, access to the Power Apps maker portal, and a role that can create solutions, tables, apps, and processes: Environment Maker, System Customizer, or System Administrator.
Use a development or training environment. This lab creates tables, publishes forms, and activates processes. None of that belongs in production while you are learning what it does.
Maker portal screens change frequently, and labels differ between the modern and classic designers. Two places in this lab drop you into the classic designer, and it looks like a different product; both are called out where they happen. If a control is not where these instructions say, check whether you are in the designer the step describes before assuming something is broken.
The five modules
Roughly three to four hours in total, and each module ends at a clean stopping point. Doing them in one sitting is not the intent.
- The data model: the solution boundary, both tables, and the lookup that joins them. 45–65 minutes.
- The model-driven app: the form, the related-records subgrid, and a published app. 20–30 minutes.
- Validation and process guidance: a Business Rule and a Business Process Flow, which stop two different things. 45–60 minutes.
- Calculated information: a rollup and a formula, with opposite timing. 35–55 minutes.
- The end-to-end test: explicit assertions, the failure paths, and the architecture interview. 30–45 minutes.
Certification
The component-selection reasoning here overlaps the material covered by Microsoft’s Power Platform architecture certification track. The lab is not an exam preparation course and does not follow any exam outline; check the current official outline if certification is your goal. The reasoning is meant to outlive whatever the exam happens to ask.
This lab is © FlowEvolve. It is free to use for personal learning. It is not licensed for redistribution or commercial training use, and unlike the articles on this site it is not published under Creative Commons.