Components, Themes, and Publishing | Guided by A Guide to Cloud

What are Power Pages components?

Simple explanation

Components are ready-made building blocks you drop onto your pages.

Think of LEGO bricks. You do not build a wall brick by brick — you grab a pre-shaped piece (a window, a door, a staircase) and snap it into place. Power Pages components work the same way.

Tom needs a list of properties on his listings page? He drops a List component. He needs buyers to submit an enquiry? He drops a Form component. Each component connects to Dataverse and handles the heavy lifting.

The key components

Component	What It Does	Tom’s Use Case
List	Displays rows from a Dataverse table in a grid or card layout	Property listings page showing all available homes
Form	Lets users create or edit a single Dataverse row	Enquiry form where buyers submit a viewing request
Multistep form	A wizard-style form split across multiple steps	A multi-page application form (name, preferences, documents)
Charts	Visual representations of Dataverse data	A bar chart showing properties by suburb
Breadcrumbs	Navigation trail showing the current page location	Home > Listings > North Shore properties
Iframe	Embeds external content inside a page	Embedding a Google Maps view of a property location

Lists: showing data from Dataverse

A List component displays multiple rows from a Dataverse table. Think of it as a dynamic table that updates automatically when data changes.

Tom added a List to his property listings page:

Data source: the Property Listings table in Dataverse
Visible columns: property name, suburb, price, bedrooms
Search and filter: enabled so buyers can search by suburb
Pagination: 12 properties per page

When an agent adds a new listing in their model-driven app, it appears on the website automatically — because both read from the same Dataverse table.

Exam tip: List vs Form

This is a core distinction:

List = shows MANY records (read-only grid or cards)
Form = shows or edits ONE record (input fields for a single row)

If the question says “display records” → List. If it says “submit data” or “edit a record” → Form.

Forms: collecting and editing data

A Form component maps to a single Dataverse row. It can be used to:

Create a new record (buyer submits an enquiry)
Edit an existing record (buyer updates their profile)
Read-only display (buyer views their booking confirmation)

Tom’s enquiry form collects: buyer name, email, phone, selected property, preferred viewing date, and a message. When submitted, it creates a new row in the Viewing Requests table.

Multistep forms: guided experiences

Sometimes a single form is too overwhelming. A multistep form splits the process into steps with a progress indicator.

Tom considered a multistep form for a buyer registration process:

Step 1: Name and email
Step 2: Property preferences (suburb, budget, bedrooms)
Step 3: Document upload (proof of pre-approval)
Step 4: Review and submit

Each step validates before moving to the next. Users can go back and change earlier answers.

When to use multistep forms

Use a multistep form when:

The form has more than 8-10 fields
Fields naturally group into logical stages
You want to reduce form abandonment (shorter steps feel less overwhelming)
You need conditional steps (show step 3 only if step 2 answer is “Yes”)

For simple forms (3-5 fields), a regular Form component is better.

Other components

Component	Details
Charts	Connect to a Dataverse view and display data as bar, pie, line, or funnel charts. Useful for dashboards. Tom added a chart showing listing counts by suburb.
Breadcrumbs	Automatically generated navigation trail. Helps visitors know where they are in the site hierarchy. Important for usability on sites with many pages.
Iframe	Embeds external content in a frame. Tom embedded a map showing property locations. Use carefully — iframes load external content, which can affect performance and security.

Modifying a Power Pages theme

The theme controls the entire visual identity of your site. You modify themes in the Styling workspace of the design studio.

What You Can Change	Where	Impact
Primary colour	Styling workspace	Buttons, links, active states across all pages
Secondary colour	Styling workspace	Accents, borders, secondary buttons
Background colour	Styling workspace	Page and section backgrounds
Header and footer	Styling workspace	Top navigation bar and bottom footer area
Fonts	Styling workspace	Heading typeface and body text typeface
Logo	Styling workspace	Site logo in the header
Custom CSS	Styling workspace (advanced)	Any override a developer wants to add

Tom’s theme customisation:

Primary colour: Summit Realty blue
Logo: uploaded the company logo
Font: a clean, modern sans-serif
Result: every page, button, and link automatically matched the brand

Theme changes are site-wide

When you change the primary colour in the Styling workspace, it updates everywhere — every button, every link, every heading accent. You do not need to edit each page individually.

This is a major advantage over building a custom website where you would need to update CSS files and ensure consistency manually.

Custom CSS: for advanced users

The Styling workspace includes a custom CSS editor for developers who want pixel-perfect control. This is completely optional — the visual theme controls handle most needs.

For the exam, know that custom CSS is available but not required. The exam focuses on the visual theme controls, not CSS syntax.

Publishing your site

Building a site is only half the job. You need to publish it to make changes visible to visitors.

Key publishing concepts:

Concept	What It Means
Preview	See your changes before publishing (only visible to you)
Publish	Push your changes live so visitors see them
Site visibility: Private	Only makers can access the site (used during development)
Site visibility: Public	Anyone can visit the site

Important: Changes you make in the design studio are not instantly visible to the public. You must click Publish (or sync) to push updates live. This gives you a safety net — you can experiment without affecting visitors.

Tom’s publishing workflow:

Make changes in the design studio
Preview to check everything looks right
Publish to push changes to the live site
Verify on the public URL

Exam tip: publish behaviour

Remember: changes are not live until published. If a question says “a maker updated a page but visitors still see the old version” — the answer is that the maker has not published yet.

Putting it all together: Tom’s finished portal

Tom started with a Copilot-generated site and built it into a complete property portal:

Page	Components Used	Security
Home	Text, images, buttons	Anonymous (public)
Property Listings	List (all properties), Chart (by suburb)	Anonymous (public)
Property Details	Form (read-only), Iframe (map)	Anonymous (public)
Submit Enquiry	Form (create viewing request)	Authenticated (Buyer role)
My Bookings	List (user’s own requests)	Authenticated (Buyer role, Contact scope)
Agent Dashboard	List (all requests), Charts	Authenticated (Agent role)

All of this runs on a single Power Pages site connected to the same Dataverse that his internal team uses in Power Apps. No code. No separate database. One source of truth.

Congratulations — you have completed Domain 5!

You now understand Power Pages: what it is, how to secure it, how to build with the design studio, and how components bring your site to life.

Quick recap of all five PL-900 domains:

Domain	What You Learned
1: Business Value	The platform, Dataverse, connectors, Copilot, Power FX, and M365 integration
2: Environment Management	Dataverse tables, environments, security model, DLP, admin centers
3: Power Apps	Canvas apps, model-driven apps, controls, sharing, and when to use each
4: Power Automate	Cloud flows, desktop flows, Process Mining, approvals, and flow logic
5: Power Pages	External websites, security, design studio, components, and themes

You have covered every objective the PL-900 exam tests. Time to revise, practice, and pass!