Page Builder

The Page Builder

The page builder assembles pages visually from widgets, rather than by writing markup.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — documents, revisions and publishing
• Pages — the site’s page structure

It builds more than pages

A document has a kind, and there are nine: page, header, footer, part, popup, email, global widget, loop item and preset.

So the same tool builds your site’s header once and uses it everywhere, designs an e-mail, and defines the repeating item used to render a list.

Parts and global widgets are the important ones

They are what stop a site being maintained page by page. A header built once as a part appears on every page and changes in one place; a global widget does the same for a block that recurs.

A site where the same block has been rebuilt on twelve pages is a site where eleven of them will be out of date.

Loop items render lists

A loop item is the design for one entry in a repeated set — a product card, a news item, a team member. Built once, applied to every row.

Each widget declares where it works

Widgets state which targets they support — web, part, popup, e-mail — and one that is not valid for the document kind is not offered. That is why the palette differs between a page and an e-mail, and it is deliberate: e-mail rendering supports far less than a browser.

Documents have a status

Draft, published, scheduled or archived. Only published and scheduled documents render publicly, so a page can be built at leisure and a change staged without being visible.

Pages connect to the site structure

A page document links to a page in the site’s own structure, which is what gives it an address, a place in navigation and its search metadata.

Start with the shared pieces

Header, footer and any recurring blocks first, then individual pages. Building pages first and extracting the shared parts afterwards is much more work.

Worked example

An organisation built its header and footer as parts, three recurring blocks as global widgets, and a loop item for its news list. A rebrand changed the header once and appeared across sixty pages.

Recommendations

• Build header, footer and shared blocks first.
• Global widgets for anything recurring.
• Expect a smaller palette in e-mail documents.
• Use draft status while building.

Building a Page

A page is built from widgets arranged into a structure, saved as a revision.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — documents, revisions and publishing
• Pages — the site’s page structure

Start from a template

Templates supply a starting arrangement by category and kind. Starting from one is faster than an empty page and produces something consistent with the rest of the site.

Presets capture your own patterns

A preset is a saved arrangement you can reuse. Once your site has a way of doing a two-column feature block, save it — the alternative is rebuilding it slightly differently every time.

Widgets have responsive settings

Each can behave differently at different widths, with per-breakpoint sizing. That is what makes a page work on a phone rather than being a desktop page squeezed.

Check every page at a narrow width. It is the most common thing left undone.

Design in blocks

A page is a stack of sections, each doing one thing. Thinking in blocks rather than in individual elements produces pages that are quicker to build and much easier to rearrange.

Reuse rather than rebuild

If a block appears on more than two pages it should be a global widget. The threshold is lower than people expect, and the cost of getting it wrong is a site that cannot be updated in one place.

Watch the accessibility settings

Widgets carry things like alternative text and whether an image is decorative. Filling those in as you build is a minute; retrofitting them across a finished site is a project.

And for some organisations it is a legal requirement rather than good practice.

Keep custom CSS in the kit

Rather than on individual widgets. Styling scattered across pages is styling nobody can change, and it is how a site drifts away from its own design.

Preview at both widths before publishing

Desktop and phone. A page that is fine on one and broken on the other is the normal outcome of building on a wide monitor.

Worked example

A team built its pages from three templates, saved two of its own arrangements as presets, and kept all custom styling in the kit. Alternative text was written as images were added rather than afterwards. Every page is checked at a narrow width before publishing.

Recommendations

• Start from a template, save your own as presets.
• Global widget anything appearing on three pages.
• Write alternative text as you build.
• Check every page narrow before publishing.

Revisions and Publishing

A document has a draft and a live revision, and every save adds to its history.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — documents, revisions and publishing
• Pages — the site’s page structure

Five kinds of revision

• Autosave — while you work.
• Manual — when you save deliberately.
• Publish — what went live.
• Import — brought in from elsewhere.
• Restore — going back to an earlier state.

Autosave does not fill your history

Deliberately. An autosave overwrites a single row per document and author rather than appending, so a day of editing does not produce four hundred revisions.

Which means autosave protects you from losing work but is not a history. If you want a point you can come back to, save manually.

Save a manual revision before anything substantial

The habit that matters. Before restructuring a page, before a large rewrite, before trying something — one manual save with a note gives you a definite point to return to.

Notes are worth writing

Each revision can carry one. "Before the pricing rewrite" is worth far more six weeks later than a timestamp, and the list of revisions is otherwise indistinguishable rows.

Saving is not publishing

The draft revision is what you are editing; the live revision is what visitors see. They move independently, so you can work on a page for a week while the current one stays up.

This is also the answer to "I changed it and nothing happened".

Publishing can be scheduled

A document carries a publish-from and publish-until, and a scheduled status. So a page can go live at a date and come down at another without anybody being there.

Useful for anything with a date attached — a campaign, a notice, a seasonal page — and it removes the risk of a page that should have been withdrawn staying up.

Archived keeps the content

An archived document is out of circulation without being destroyed. Prefer it to deletion; a page you might need again, or might be asked about, is worth keeping.

Documents can be locked

A document records who has it locked and when. That is what stops two people editing the same page and one silently losing their work.

If a page is locked by somebody who has gone home, that is a person to ask rather than a fault.

Worked example

A team saves a manual revision with a note before any substantial change, and schedules seasonal pages to publish and unpublish on dates. A restructure that went wrong was reverted to a noted revision in under a minute.

Recommendations

• Manual save with a note before anything substantial.
• Remember autosave is not history.
• Schedule dated pages to publish and withdraw.
• Archive rather than delete.

Page Access

A page can be public or restricted, with four modes of increasing strictness.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — documents, revisions and publishing
• Pages — the site’s page structure

Admin Panel → User Administration:

• User Groups — the groups a page can be restricted to

Architect Panel → Security:

• Permissions — the record gate the strictest mode uses

The four modes

• Public — anybody. A page with no rule is public.
• Signed in — any identified user.
• Group — members of named security groups.
• Record — delegated to the platform’s own record access check.

The record mode is the powerful one

Rather than restating a rule, it asks the platform whether this person may see the record the page is bound to. So classification, lifecycle, record access roles and break-glass all apply without the page needing to know they exist.

That is the mode for a page showing somebody’s case, order or account.

It fails closed

If the access check cannot be performed, the answer is no. That is the correct behaviour and worth knowing, because it means a misconfiguration produces a page nobody can see rather than one everybody can.

A refusal does not admit the page exists

By default. Somebody probing for a members area learns nothing from the response, which is the right default for anything sensitive.

Turn on the login redirect deliberately

A separate setting sends an unauthenticated visitor to sign in instead. That is friendlier and it discloses that the page is there.

Right for a customer portal a user is expected to reach; wrong for anything whose existence is itself sensitive.

Being in no groups is not the same as unresolved

A subtlety the platform handles explicitly, and one worth understanding: a user whose groups have not been worked out yet is not a user with no groups. Treating them the same grants access to everybody or to nobody.

The practical consequence is to test with a real account rather than reasoning about the configuration.

Test every mode with the right accounts

Signed out, signed in without the group, signed in with it, and for record mode a user with and without access to the record. Four accounts, four results.

Public by omission is the risk

A page with no access rule is public. When building a restricted section, confirm each page carries a rule rather than assuming it inherited one.

Worked example

A customer portal uses record mode for case pages, group mode for its account section, and a login redirect on both because users are expected to arrive there. A check found two pages in the restricted section with no rule at all, which were public.

Recommendations

• Record mode for anything showing one person’s data.
• Confirm every page in a section carries a rule.
• Login redirect only where the page’s existence is not sensitive.
• Test with four accounts, not by reading the configuration.

The Visual Page Builder

The visual page builder produces nested flex and grid documents that render as web pages — and, from the same tree, theme parts such as headers and footers, popups, and e-mail templates.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — the builder itself
• Pages — the pages in your site
• E-mail Templates — templates the builder can produce
• Header — the site header as a theme part

One tree, four outputs

The same document structure renders to several targets. A web page and an e-mail need very different HTML — e-mail requires tables and inline CSS to survive older clients — but you build once and the renderer handles the difference.

That matters practically: your brand, spacing and colours are defined in one place rather than diverging between the website and the emails it sends.

Documents, revisions and publishing

A page is a document with revisions. You can work on a draft without affecting what visitors see, and publish when it is ready. Because revisions are kept, reverting is possible — which makes editing a live page far less nerve-racking.

Access control

Pages carry access control, so a page can be public, restricted to signed-in users, or limited to particular groups. That is enforced when the page is served rather than by hiding a link.

It coexists with the legacy pages

The older page system still dispatches, so existing pages carry on working. You do not have to migrate anything to start using the visual builder for new pages — and the friendly URL behaviour documented for the legacy system still applies.

When to use which

• The visual builder — anything with layout: landing pages, portal home pages, styled emails, popups.
• The legacy pages — existing pages that work, and anything already built.

Worked example

A council builds a self-service portal home page in the visual builder: a header theme part shared with every page, a grid of service tiles, and a popup for service announcements. The same header is used by the confirmation emails, so a rebrand later is one change rather than a hunt through templates.

Recommendations

• Build the theme parts first. Header and footer shared across pages save the most work later.
• Preview the e-mail target specifically — it is the one most likely to surprise you.
• Publish deliberately and keep drafts for anything substantial.
• Set access control when you create the page, not after somebody finds it.

Design Kits

A kit holds the design decisions a site shares: colours, fonts, typography, defaults and custom styling.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — documents, revisions and publishing
• Pages — the site’s page structure

Architect Panel → Styling:

• Logo — the wider application theme

What a kit holds

A named set of colours, fonts, typography settings, widget defaults and custom styling, with a revision so changes are tracked. One kit is the default.

Decide it once

The whole value. Colours and type chosen in the kit apply everywhere; the same decisions made per widget apply nowhere else and diverge immediately.

A site styled widget by widget is a site that cannot be rebranded.

Keep custom styling in the kit

Rather than on individual widgets and pages. Styling scattered across a site is styling nobody can find, and it is the reason a "simple" colour change turns into a week.

Fewer colours than you think

A primary, a secondary, a background, a text colour, and one or two for states. A palette of fifteen is a palette used inconsistently.

Check contrast properly

Text against its background, at the sizes actually used. A palette that looks elegant on a designer’s screen can be unreadable on a phone outdoors, and for many organisations accessible contrast is an obligation rather than a preference.

Typography carries most of the feel

Heading sizes, line height, spacing. Setting these deliberately in the kit is what makes a site look designed rather than assembled, and it costs one sitting.

Widget defaults save repetition

Where the kit sets a default, every new widget starts correct. That is worth more than it sounds — it means somebody building a page produces something consistent without knowing the rules.

Change the kit, not the pages

When the design changes. A rebrand should be a kit change that propagates, and if it is not, styling has leaked onto pages and that is the thing to fix.

Test a kit change broadly

It affects everything. Look at several pages of different kinds — a text page, a page with a form, an e-mail document — before considering a kit change finished.

Worked example

An organisation defined a five-colour palette and its typography in the kit, with all custom styling there rather than on pages. A rebrand was a kit change checked across six representative pages, and took an afternoon rather than a project.

Recommendations

• All styling in the kit, none on pages.
• Five or six colours, used consistently.
• Check contrast at real sizes.
• Test a kit change across several page kinds.

Widgets, Themes and Styling

A page is a tree of nodes, and what each node may contain is defined by a widget registry. Widgets are the building blocks — text, images, grids, buttons, data blocks and the rest.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — where widgets are placed and styled
• Header — the header theme part
• E-mail Designs — design assets used by templates

Architect Panel → Styling:

• Logo — the site-wide styling the builder inherits

The registry decides what fits where

Not every widget may sit inside every other. The registry validates the tree, so a layout that could not render is rejected as you build rather than producing something broken when published.

Theme parts

A header or footer built once and shared is a theme part. Change it and every page using it changes.

This is the single biggest time-saver in the builder, and the thing most worth setting up before you build many pages — retrofitting a shared header across twenty individually-built pages is a tedious afternoon.

Popups

Popups are documents like any other, so they use the same widgets and styling. Use them sparingly: a popup on every visit is the fastest way to train people to dismiss without reading.

Styling and the asset cache

Styles are compiled and cached as assets rather than being emitted inline on every request. That keeps pages fast, and it means a style change is picked up when the asset recompiles.

If a style change does not appear, that cache is the first thing to check — this is the commonest confusion when two people are editing.

The e-mail target is different

E-mail rendering produces table-based layout with inline CSS, because that is what mail clients reliably support. Flex and grid do not survive in many of them.

The builder handles the translation, but the result is not pixel-identical to the web version. Always preview the e-mail target, and send yourself a test to a real client before using it in anger.

Worked example

A service builds one header theme part with the logo and main navigation, and one footer with contact details and the accessibility statement. Eleven portal pages use both. When the accessibility statement is updated, one edit updates all eleven — and the confirmation emails, which use the same footer.

Recommendations

• Theme parts before pages.
• Test emails in a real client, not only in the preview.
• Keep the widget tree shallow. Deeply nested layouts are hard to edit and slow to render.
• Check the style cache when a change does not show.

Page Addresses

A page’s address is what people bookmark, share and find in search results. It deserves more thought than it usually gets.

Where to find it

Architect Panel → Layout & Pages:

• Page Builder — documents, revisions and publishing
• Pages — the site’s page structure

Architect Panel → Configuration:

• Friendly URLs — generated addresses for records
• Search Engine Optimisation — how pages are presented

Pages against records

A page in the site structure has an address you choose. Addresses for records are generated by friendly URL rules from a field — a different mechanism, covered under Site Configuration.

Both end up as readable addresses; only one of them is something you type.

Choose short and descriptive

Lower case, hyphens between words, no dates, no version numbers, no internal codes. The address should say what the page is to somebody who has never seen your site.

Reflect the structure

A page nested under a parent should have an address that shows it. Readers use addresses to understand where they are, and search engines use them to understand your structure.

Do not put dates in

The most regretted choice. An address containing a year is an address that looks stale next January, and changing it breaks every link to it.

Addresses should not change

Once a page has been published, its address has been shared, indexed and bookmarked. Changing it breaks all of that silently — nobody tells you that a link in somebody’s e-mail from March stopped working.

Spend the extra minute before publishing rather than the hour afterwards.

When one has to change

Put a redirect in place from the old address, and expect it to be needed for years. A redirect is cheap; a broken link on a page you cannot edit is permanent.

Watch for collisions

Page addresses and generated record addresses share the same space. A page at a path that a friendly URL rule also generates under is a conflict, and the symptom is one of them resolving to the wrong thing.

Keep record rules under their own root and page addresses out of it.

Set the canonical too

Where a page is reachable by more than one address, the canonical says which one counts. Without it a search engine chooses, and it may not choose the readable one.

Worked example

A site uses short hyphenated addresses reflecting its structure, with no dates. Record addresses live under their own roots so they cannot collide with pages. A page that had to move kept a redirect, which was still receiving traffic eighteen months later.

Recommendations

• Short, lower case, hyphenated, no dates.
• Settle the address before publishing.
• Redirect whenever one must change.
• Keep record roots separate from page addresses.