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.

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.
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.
   • 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.

Personal links in bulk

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 — ready to merge into a broadcast so every newsletter contains that person’s one-click unsubscribe.

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.