Help

The Preview step runs your draft in the real participant app, inside the editor, at three device widths. Nothing you do there is visible to anyone else — the live portal keeps serving whatever you last published. This guide covers what the preview does show, the two things it deliberately does not, and a checklist to run before you publish.

Opening the preview

In the portal editor, click step Preview in the bar at the top.
The portal loads in a frame — the actual participant app, running your draft.
Use the Desktop / Tablet / Mobile buttons above the frame to change the width.

If the preview does not load, check Portal ID in the Branding panel. The preview address is built from it, and the field says so: “Set a Portal ID to enable the live preview.”

Switching back to Design and editing pushes your changes into the frame as you make them — pages, layouts, the menu, the logo, the login title and description all update without a reload. Preview always reads your draft, never the published site.

The three device widths

Desktop 1280, Tablet 768, Mobile 390. Both the tablet and the phone frame get the phone chrome — the fold happens at the same width a real device folds at.

If a nav container in the active layout is set to Stack or Scroll sideways under On mobile, the narrow frames keep your authored menu instead of the app shell. This is the surface that tells you the truth about phones: the Design canvas draws the menu as authored whatever the knob says, and only badges a Menu-button nav with App shell on phones.

What to walk through

The frame is fully interactive. Click your way around as a participant would:

Every menu entry lands on the page you expect, and the page you marked as the default opens first.
Lists fill with rows, and clicking a row reaches the matching detail page with the right record loaded.
Blog cards link to real post addresses built from the post’s slug, and the post page shows the cover, title, date, body and tags you expect.
Metric cards show numbers rather than an error — an error usually means the entity or filter is misconfigured.
Your logo appears in the header, the drawer and on the sign-in screen; the login title and description read correctly in every language you support.
At phone width, tap targets are comfortable and wide tables stay readable.

Two things preview cannot show you

The preview is a signed-in view of the draft. The anonymous view is created by the server, so it only exists once the portal is published.

The signed-out experience

In preview you are always a signed-in user, so the preview cannot show you what an anonymous visitor gets. In particular, the menu links the public site strips are still drawn. The designer flags them instead: in the Design canvas such a link renders dimmed with a small lock, and the link editor offers Use Sign In. Trust the lock badges, not the preview.

One case to watch: a “Register” link in a public menu does work in preview but is removed on the live public page — Sign In is the only app route a public menu may point at. Point visitors at Sign In; the sign-in screen carries its own registration link when self-registration is on.

Because the preview persona is already signed in, clicking a Sign In or Register link does not open a login form. It takes you to the page you marked Default page after sign-in — which mirrors what a real sign-in does, minus the form. If no page is marked, the click does nothing at all. That is a useful signal in itself: a portal with no default page after sign-in has nowhere to put a participant.

Hidden pages

Pages you have hidden with the eye icon are fully visible in preview — that is the point of hiding them. They will not exist on the published site, and neither will links to them. The Publish step tells you how many there are before you go live.

Pre-launch checklist

Pages and routing

Every page is reachable from a menu or a list row. A public page is marked Default public page and a private one Default page after sign-in. No menu entry points at a slug that no longer exists.

Access

Each page has the right level under Who can see this page. Nothing private is accidentally public. No lock badge is left unexplained in a public menu.

Data

Metric cards show numbers. Lists show columns and rows. Row actions reach the right detail page. Blog listings link to post pages by slug.

Branding

Your logo shows in the header, the drawer and on the sign-in screen. The login title and description are filled in for every language.

Phones

Check at Mobile width. If a menu should keep its own design, set On mobile to Stack or Scroll sideways. Remember the app shell shows at most five bottom tabs — the rest live in the drawer.

Public pages have a Search title and Search description. Anything not meant for search has Hide from search engines switched on.

Domain

A verified domain is selected as the Panel domain in Branding. Without it, publishing is refused.

Sign-up posture

Allow self-registration and Auto-approve sign-ups are set the way you want. Both take effect immediately, without a republish.

Finish the check on the live site

Once you publish, do one more pass that preview cannot do for you: open your domain in a private browsing window, so you arrive signed out. That is the only place you see the real anonymous menu, the real sign-in screen, and the public pages exactly as a search engine will index them.

Next step

When the checklist is clear, continue to Publishing and Launching Your Participant Portal. To revisit the design surfaces, see Building Your Portal — Design Tabs, Components and Branding.