Portals

Portals let people outside your workspace act on their own data — update their details, register, unsubscribe, confirm attendance — through clean, mobile-friendly public pages, without an account or a login. A portal is pure configuration: you choose the record type it serves, how visitors prove who they are, and which of your forms and reports make up its pages.

Enabling the add-on

Portals are an add-on: enable it in Admin → Marketplace first. Once enabled, Admin → Portals appears; until then, no public portal link works — as if the feature didn’t exist.

Three ways in

Each portal has an access mode — how a visitor is matched to their record:

• Action links — a single-use link that does exactly one thing: unsubscribe this person, confirm this registration, approve this request. You mint the link for one record and one action; the visitor sees what it will do, confirms, and the link burns — it can’t be reused.
• No-login access links — a personal link that opens the whole portal as one person, no code or password. Ideal inside emails: “view and update your details” as one click.
• Email-code (OTP) portals — the visitor enters their email address and receives a 6-digit code; entering it opens their portal session. Nothing is ever revealed about whether an email exists, and codes expire quickly. The session survives a page refresh in the same browser tab and lasts 30 minutes; after that (or in a new tab) the visitor requests a new code.

All links are unguessable and time-limited, and every action a visitor takes lands in the record’s history like any other change.

Building a portal

1. Open Admin → Portals and click + New portal — name it and pick the record type the portal serves (the subject: usually your Person type).
2. Choose the access mode and, for email codes, the email field used to find the person. The optional Intro text shows under the portal’s name — on the email-code screen and at the top of every page once the visitor is in.
3. Compose the pages — each page is a list of components:
   • Form — one of your generic forms, resolved for the visiting person: they see and edit exactly the fields you placed, with the same required rules and validation as in the app. Workflow transition buttons on the form work too. A form can also create a new record instead — a survey response, a registration, a request — see Forms that create records.
   • List — a report scoped automatically to the visitor: their payments, their registrations. A report that can’t be scoped to the visitor shows nothing — data never leaks.
   • Text — instructions, headings, a welcome message.
   • Action — a button: save, a workflow transition, or self-delete (the person can erase themselves).

Portal pages live outside the app shell — no sidebar, no login — and work well on phones. They carry your workspace branding automatically: the logo and accent colour from Admin → Branding show in the page header, browser tab title and favicon, so the public pages look like yours, not PeoplePit’s. While a page’s content is loading, visitors see a subtle placeholder instead of an empty or misleading message.

Forms that create records (surveys, registrations…)

By default a Form component edits the visitor’s own record. Switch its mode to Creates a new record and each submission creates a record of another type instead — linked to the visitor, and to whatever the link was about. This is how you collect a post-event survey, a session registration, a support request or an application: the responses are ordinary records you can list, filter, report on and automate.

Configure it on the component in Admin → Portals:

• Record type created — the type each submission creates (e.g. Survey). It’s preselected from the form’s type assignment.
• Link to the visitor via — a reference field on that type pointing at the portal’s subject type (e.g. Respondent → Person). It is filled with the visitor automatically.
• Fields filled from the link — reference (or other) fields set from the personal link’s parameters, e.g. Event ← ?event=…. The value comes from the link you sent, never from the visitor: it shows read-only on the form and can’t be changed. A link without the parameter shows a “this link is missing information” notice instead of the form.
• Pre-filled values — fields shown with a value already selected that the visitor can still change: from a link parameter (e.g. Rating ← ?rating=…), from a fixed value (e.g. always 5), or both (the link wins, the fixed value is the fallback). Pre-filled values only apply to a new response: a returning visitor always sees exactly what they saved. On a field the visitor can’t edit the pre-filled value is fixed instead: it’s shown locked, always saved, and can be used under One response per. A field is non-editable for visitors when the form marks it read-only — or when it references another record (an Event, a Person…): visitors never get a record picker, since it would let outsiders browse your records. This is how a portal opened with an email code (no personal link to carry parameters) pins its event: Event ← fixed value E-12, One response per Invited by + Event.
• One response per — tick the link fields that make a response unique (e.g. Respondent + Event: one survey per person per event). When they come back, a visitor either edits their earlier response (the form reopens with their answers) or sees the thank-you message. Leave it unticked to allow any number of submissions.
• Submit button and Thank-you message — your own wording (translated like other portal labels when left empty).

Only the fields you placed on the form are filled by the visitor; everything else on the new record comes from your configuration. The created record goes through the normal engine — validation, numbering, workflow start, automations and notifications all apply.

Example: a survey after an event

1. A Survey type with Respondent (reference → Person), Event (reference → Event), Rating (a Rating field) and Feedback (rich text).
2. A form in Admin → Forms with the Rating and Feedback fields (add Event too if visitors should see which event they’re rating — it shows read-only).
3. A portal over Person with a page holding that form in Creates a new record mode: type Survey, link via Respondent, Event ← event, one response per Respondent + Event.
4. The invitation: a notification rule on the Event (e.g. when its workflow moves to Completed), delivered individually to its attendees, with {{recipient.portalLink.<portal-slug>?event=id}} in the body. Sending from a Campaign record that references the event instead? Use ?event=<campaign's event field>.

Clickable stars in the email. Add Rating ← rating under Pre-filled values, then put five links in the message, one per star, each carrying its score:

<a href="{{recipient.portalLink.<portal-slug>?event=id&rating=1}}">★</a>
<a href="{{recipient.portalLink.<portal-slug>?event=id&rating=2}}">★</a>
<a href="{{recipient.portalLink.<portal-slug>?event=id&rating=3}}">★</a>
<a href="{{recipient.portalLink.<portal-slug>?event=id&rating=4}}">★</a>
<a href="{{recipient.portalLink.<portal-slug>?event=id&rating=5}}">★</a>

Clicking the fourth star opens the survey with four stars already selected; the attendee can adjust it, add a comment and submit. Nothing is saved by the click alone. Once they’ve responded, any star link reopens their saved answers (which they can still edit).

Each attendee opens a personal link, picks their stars, writes a comment and submits — a Survey record appears, linked to them and to the event. A report grouped by Event with the average of Rating gives you the scores.

Link previews when sharing

When a portal link is posted on a social network or in a messaging app (Facebook, WhatsApp, LinkedIn, X, Slack, Telegram…), the preview shows the portal — not just a bare address. Set it in Admin → Portals → your portal → Sharing (link preview):

• Title — e.g. Portail d’invitation. Empty = the portal’s name.
• Description — e.g. Portail d’Invitations au prochain évènement des Musicales du Liban à Paris. Empty = the portal’s intro.
• Image URL — an image reachable on the web (https://…), ideally 1200×630. Empty = your workspace logo from Branding, when it’s a web address.

The title and description are translatable like the rest of the portal (Admin → Translations) and appear in the workspace’s default language. Personal and action links show the same preview as the portal — never anything about the person the link belongs to, since anyone in the conversation can see it.

Networks keep previews in cache: after changing the texts, refresh an already-shared link once in Facebook’s Sharing Debugger or LinkedIn’s Post Inspector; WhatsApp refreshes on its own after a while.

Personal links in emails

The simplest way to put a personal portal link in front of people is to merge it into a notification or broadcast: write {{recipient.portalLink.<portal-slug>}} in the message and every recipient gets a fresh, private, expiring no-login link to their own record — minted while the mail is built, nothing to generate beforehand and nothing stored on the record. Pair it with the rule’s Unsubscribe header so mail clients show a native Unsubscribe button. See Notifications → Merge fields. The links expire after the portal’s link expiry (30 days by default; linkTtlDays in the portal’s config).

A link can carry parameters for forms that create records: {{recipient.portalLink.<portal-slug>?event=id}}. The parameters are sealed into the link — the visitor can’t edit them. The Generate no-login link box in the portal editor accepts them too (event=E-100003, several separated by &), for testing or a one-off link. After generating, the editor shows what the link carries — and warns in red when the portal’s forms expect a parameter the link doesn’t have (such a link opens on a “missing information” notice instead of the form).

Personal links in bulk

When a link must live on the record — to show it in a list, export it, or use it outside email — the Bulk no-login links panel generates one personal access link per person and stores it in a Hyperlink field on each record:

1. Select the people — explicitly, or with any filter (“subscribed people in campaign X”).
2. Pick the target Hyperlink field (e.g. Unsubscribe link), a label, and an expiry.
3. Preview the count, then Generate & store.

Each record now carries its own private link, which templates can also merge with {{recipient.unsubscribeLink.url}}.

Language

Visitors have no account, so a portal page doesn’t know a personal language preference. It renders in the workspace’s default language (Admin → Translations → “Default language for this tenant”), covering both the page’s own wording (buttons, prompts, messages) and your configuration: field labels, picklist values, workflow and state names, transition buttons, the portal’s own name, intro, page titles and text blocks, and every label typed into its forms come out translated exactly as in the app, using the same translation packs — each of them is an entry in the Configuration part of the pack.

A link can carry a language explicitly: add ?lang=fr to any portal URL (action link, personal access link, or the OTP entry page) to open it in that language, provided it is enabled in Translations. A requested language the workspace doesn’t have falls back to the default, and no default means English. Right-to-left languages flip the page direction automatically.

What visitors can and can’t do

A portal session is hard-scoped to one person and to what you configured: only the fields on your forms are editable, only the transitions you exposed can fire, and only reports you placed — scoped to the visitor — are visible. Everything else in your workspace simply doesn’t exist from the portal’s point of view.