Pages and templates give a site its structure and look. But structure alone doesn't show anyone actual data. To put real Dataverse records in front of a visitor — or collect new ones back — a page needs one of two building blocks: a List for showing existing records, and a Form for creating or editing one.
- A List shows a filtered, paged set of existing records — the portal equivalent of an internal View
- A Form lets a visitor create or edit a record — the portal equivalent of an internal Form
- Both are normally scoped down hard, so a visitor sees only records relevant to them
- What enforces that scoping is table permissions, covered next chapter
Lists: a filtered, paged window into Dataverse
A List displays records from a table, filtered to whatever's relevant, and broken into pages so a visitor isn't handed a thousand rows at once. If you've covered Views in the Customization course, this is immediately familiar — a List is the Power Pages equivalent of a View, rendered for a visitor instead of an internal user.
Same underlying idea either way: pick a table, decide which columns show, decide which records qualify through a filter, and let the visitor page through the results.
The key difference isn't the mechanics — it's the audience. A List on a portal is normally scoped down hard, so a visitor only sees records relevant to them (their own company's cases, their own orders), never the entire table. Chapter 4 covers exactly how that scoping is enforced.
Forms: letting a visitor create or edit a record
A Form lets a visitor submit new information directly into Dataverse, or edit an existing record they're allowed to touch — a support case submission, an updated contact detail, a quote request. This mirrors the internal Forms concept: fields grouped into a layout someone fills in to create or update a record.
A portal Form works the same way in spirit, but scoped down deliberately:
- An internal Case form might show a dozen fields, including staff-only ones like internal notes or assignment details
- A portal Form on that same table typically shows only a handful of fields appropriate for an outside visitor — subject and description, say
- Every internal-only field stays off the portal form entirely — the visitor never even knows they exist
A library card catalog and a request slip
A List is like a library's card catalog: you browse and search, and it shows a filtered set of what's already there — you can look, but not change it. A Form is like a request slip at the front desk: you hand over information for the library to act on.
| Building block | Purpose | Internal equivalent |
|---|---|---|
| List | Show a filtered, paged set of existing records | View |
| Form | Create or edit a record from the portal | Form |
Together, a List and a Form cover most of what a visitor does on a data-driven Power Pages site: browse what's already there, then optionally add or update something themselves. What decides exactly which records and fields they can reach through either one is a separate concern — important enough for its own chapter next.