Every earlier chapter covered one piece of Power Pages on its own — what it is, how it's structured, how it shows and collects data, and the two-layer security model that keeps it safe. This capstone walks through one small, realistic scenario that uses every piece together, so they stop feeling like five separate ideas and start feeling like one coherent system.
- Scenario: a customer self-service portal built on the Case table
- Uses pages, a template, a List, two Forms, a table permission, and a web role
- Same five pieces cover most Power Pages self-service scenarios you'll build
The scenario: a customer self-service portal
Picture the storefront-and-back-office idea from Chapter 1, focused on one counter: customer service. A software company already tracks support requests internally as Cases, the same Case table covered in the Customer Service Basics chapter of the Core Modules course.
Rather than making every customer call or email to check on a request, the company builds a small Power Pages portal so customers can see what's open, check a specific one, or ask for help with something new — all from that one counter.
Step 1 — Pages and templates
The portal starts with a small page hierarchy: a Home page, a "My Cases" page, and a "Submit a Case" page, all sharing one template that defines the header, footer, and overall look. Just like the picture-frame idea from Chapter 2, that template stays fixed while each page slides its own content into it — Home shows a welcome message, "My Cases" shows a list, "Submit a Case" shows a form.
Step 2 — A List of the customer's own Cases
The "My Cases" page uses a List pointed at the Case table, showing columns like subject, status, and date opened. Left unscoped, that List could show every Case in the entire company — every customer's business, all in one place. That's exactly the gap Chapter 4 warned about.
Step 3 — A Table Permission scoped to Contact
To close that gap, a table permission on the Case table is set with a scope of Contact and Read privileges. That single setting turns the List from "every Case in the company" into "only the Cases where the Case's Contact field points to this signed-in visitor's own Contact record." The List's layout doesn't change at all — only what it's allowed to return per visitor does.
Step 4 — A Form to view details, and another to submit a new one
Clicking into one Case from the List opens a Form showing that Case's details — subject, description, and current status — the same List-then-Form pattern from Chapter 3. A separate "Submit a Case" page holds a second Form for creating a brand-new record: the customer fills in a subject and description, and submitting it creates a new Case directly in Dataverse, automatically linked to their own Contact record.
Step 5 — Authentication and the Web Role tying it together
None of the scoping above means anything until the portal knows who's asking. The customer first authenticates — signing in with a local Power Pages account, or through an external identity provider — and that identity is assigned a Web Role, say "Customers." That Web Role links the signed-in visitor to the Contact-scoped Case table permission from Step 3.
A visitor browsing the same portal without signing in falls under Anonymous Users instead, which grants no access to the Case table at all — they'd see the public Home page and nothing more.
| Chapter | Piece | Role in this scenario |
|---|---|---|
| 2 | Pages & Templates | Home, My Cases, and Submit a Case pages sharing one template |
| 3 | List | Shows the customer's Cases on "My Cases" |
| 3 | Form | Shows Case details, and collects a new Case submission |
| 4 | Table Permission | Scopes the Case table to Contact, Read + Create |
| 5 | Authentication & Web Role | Confirms identity, links the visitor to the table permission |
Every piece here is doing exactly what its own chapter described, with nothing new introduced — the only thing this chapter adds is seeing them click together into one working counter a real customer could use.
Where to go from here
This course deliberately kept the internal security model — security roles, business units, the model-driven app itself — out of scope, since Power Pages runs its own separate system for external visitors. If you haven't already, the existing deep-dive tutorial D365 CRM Fundamentals & Configuration covers that internal side in full.
And since this capstone was built around Cases, the Customer Service Basics chapter in the Core Modules course is a natural companion, covering how that same Case table works for internal support staff on the other side of the counter.