A participant portal is a complete website served on a domain you own — public pages anyone can read and search engines can index, plus a private, signed-in area wired to your organization’s own surveys, responses, scores and records. One portal covers both audiences. You design it in SurveyAnalytica, publish it, and it answers on yourbrand.com with your logo in the corner and no SurveyAnalytica branding in the address bar.

One site, two audiences

This is the single idea that shapes everything else. A portal serves two kinds of people from the same set of pages:

Because both live in one design, the handover is seamless: a visitor reads your services page, clicks Sign In in the same menu, and lands in the private area without ever leaving your domain.

Every page picks its own audience

In the page settings, Who can see this page offers three levels:

The boundary is enforced on the server, not by hiding things in the browser. On a page an anonymous visitor can read, menu links pointing at private pages are removed outright — even the label of a private page never prints on a crawlable page. That is why a public menu’s sign-in button has to point at the app’s own Sign In route rather than at a private landing page; the portal designer flags such links for you while you are authoring.

Two front doors

Because a portal serves both audiences, it has two landing pages rather than one. In the page settings, a public page can be marked Default public page (“Opens at / for visitors who are not signed in”), and a private page can be marked Default page after sign-in (“Opens at / for signed-in participants”). Both can be set at once; each answers / for its own audience. That is what lets a marketing home page and a participant dashboard share the root of your domain.

What it looks like on a phone

Portals are responsive by default. On phone widths the platform normally replaces your menu with an app shell — a top bar with a menu button, a slide-out drawer, and bottom tabs built from the same links. That is the right behaviour for a signed-in dashboard, and it is what a nav container does unless you say otherwise.

For a public marketing header it is often not what you want, so the nav container’s On mobile knob lets you keep your own design: Stack keeps the authored menu with its mobile styles, and Scroll sideways keeps it as one row that swipes across. Menu button (the default) hands phones to the app shell.

What people build with it

The building blocks

A portal is pages, wrapped in layouts, filled with components.

• Layouts are the chrome — a sidebar or a top bar, a footer, and one page-content injection point. Most portals use two: a public one and a private one.
• Navigation is a nav container you place in a layout, with each menu entry a real link you can select, style and re-point. (Older portals that had a separate navigation model were migrated into this automatically.)
• Content blocks — headings, paragraphs, images, buttons, sections and rows — build the pages a visitor reads.
• Data blocks — Data Metric for one aggregated number, Data List for a paginated table, Data Detail for one record read from the URL.
• Participant blocks — Responses, Scores, Profile, Widgets and Surveys, each already scoped to the signed-in person.
• Blog blocks — Blog Listing and Blog Details. Posts are addressed by readable slugs, so an article lives at /blog/shoulder-stiffness-after-surgery rather than an opaque id.

Branding, domain and sign-up

• Your logo, everywhere. The portal’s own branding logo is used across the site, the sign-in page, the register page, the mobile app shell and the browser icon. Your organization picture is only the fallback for a portal that has not set one.
• The sign-in screen is yours. Login title is the headline; Login description is the short text under it. Both are translatable.
• Your domain. A published portal is served on a hostname you own and have verified, and every link, email and QR code uses it.
• Sign-up is per portal. Allow self-registration in the Branding panel decides whether strangers can create an account at all, and Auto-approve sign-ups in the Settings popover decides whether they get in immediately or wait for an admin. Switched off, “new sign-ups wait for an admin’s approval before they can access this portal”.

Languages

Page titles, menu labels, headings, paragraphs, button text, the login title and the login description are all per-language. Add the languages your audience needs in the designer and fill each one; anything untranslated falls back to the portal’s default language.

The setup path

1. Set up a custom domain and verify it.
2. Build the portal — pages, layouts, components and branding.
3. Preview and test it at desktop, tablet and phone widths.
4. Publish it and share the URL.