We use cookies
We use cookies and similar technologies to improve your experience, analyse traffic, and personalise content. You can accept all cookies or reject non-essential ones.
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.
This is the single idea that shapes everything else. A portal serves two kinds of people from the same set of pages:
They see only the pages you marked public. Those pages are rendered on the server, so they are fast, shareable and indexable — a real marketing site, not an app behind a login.
They get everything the visitors get, plus your private pages: their surveys, their responses and scores, their profile, and any records you choose to surface.
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.
In the page settings, Who can see this page offers three levels:
| Level | Who reads it | Search engines |
|---|---|---|
| Private | Only signed-in participants. | Never reachable. |
| Public | Anyone on the internet, no sign-in. | Server-rendered and indexable. |
| Public, richer when signed in | Anyone can read it; signed-in participants see more on the same page. It appears in both menus. | Indexable, in its public form. |
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.
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.
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.
Public pages for services, the team and online booking, plus a private patient area for upcoming appointments and recovery progress — one domain, one design.
A public sign-up page that explains the programme, and a private area where each panelist sees the surveys assigned to them, their submission history and their certificates.
Assigned tests, scores with per-attempt breakdowns, a leaderboard built from a Data List with per-user filtering turned off, and downloadable certificates.
A public knowledge base and contact page — indexable, so people find the answers from a search engine — with a private area for raising and tracking tickets.
Metric cards for open returns, active warranties and pending invoices, each drilling from a list into a detail page for one record.
Compliance sign-offs, annual surveys and policy acknowledgements, with different domains serving different teams inside the same organization.
A portal is pages, wrapped in layouts, filled with components.
/blog/shoulder-stiffness-after-surgery rather than an opaque id.Self-registration works on your own custom domain only. The shared preview host is for previewing a draft from a browser tab — it does not accept sign-ups. Map a domain before you invite anyone.
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.