Portals is in Alpha and isn’t in the main sidebar yet. Go straight to app.statisfy.com/portals — it’s worth bookmarking. Anyone on your team can open it.
Setup at a Glance
Steps 1–2 and 5 happen once per portal. Steps 3–4 happen once per account you onboard, so they keep going as you add customers.
Step 1: Create Your Portal From a Template
Open the Portals page at app.statisfy.com/portals and select Create new portal. Pick a template — select Live preview on a template card to see what it looks like first — give the portal a name, and select Create portal. Statisfy opens it in Portal Studio. Full walkthrough: Creating a Portal. A new portal starts as a Draft. Nothing is customer-facing until you go live in Step 5.Step 2: Customize It
Portal Studio is the in-browser editor. Two things matter for setup:- Code — your portal’s files, built with React and TypeScript. Edits autosave as a draft, so the live version never changes underneath you.
- Settings → Components — where you tell each ready-made Statisfy component which data or worker it should use. Unlike code, these need an explicit Save changes.
Customizing With Claude
You don’t have to edit the code by hand. Statisfy has a Portal MCP server, so Claude (or another MCP client) can work on a portal directly: list your portals, read and edit files, validate the changes, and deploy a preview URL for you to review. Connect it once — add a custom connector pointing athttps://api.statisfy.com/mcp/portal and authorize it — then ask in plain language:
“Change the welcome heading on the Acme portal and give me a preview link.”Edits go to your draft, and the assistant can build and deploy a preview. It cannot publish to your live site: going live stays a human action in Portal Studio. Setup, the full tool list, and troubleshooting: Portal MCP Server.
Step 3: Point Each Account at Its Onboarding Project
If your portal shows a customer their onboarding project — the Project module — it doesn’t guess which project that is. It reads a field on the account. Every account in Statisfy already has a built-in Onboarding Project field: a Lookup – Project field that names the one project this account’s portal should show. Until you set it, a customer can sign in perfectly well and still find the project area empty.Setting it
You don’t need a portal permission for this — it’s an ordinary account edit, so any team member who can edit customer data can do it. Note that a Member only sees the accounts in their own book; Member All Accounts, Builder, and Admin see every account. Open the account, find Onboarding Project, search for the project by name, and select it. To point many accounts at their projects at once, use bulk edit — select the accounts, choose the field, and link them. The mechanics are the same as any other lookup field; see Lookup Fields.How the portal uses it
- Once per account, not once per portal. When a customer signs in, the portal reads the field on their account. One field per account serves every portal you build, so there’s nothing to wire up per portal.
- The Project module reads it automatically. In Portal Studio this appears as a Locked property under Settings → Components — Statisfy resolves it per signed-in customer, which is why it’s read-only there and why you don’t need to configure it.
- It’s also the boundary. A portal only ever shows the project the signed-in customer’s own field points at, so one account’s project can’t surface on another’s portal.
Step 4: Set Up Who Can Sign In
This is the step that’s easiest to miss. A customer needs two things to sign in:- A contact record — they exist in Statisfy as a person on the account whose data they should see.
- A grant — the portal’s Access tab admits them, by email, by their whole email domain, or by a rule on people’s fields.
Adding that contact is an ordinary customer-data edit — no portal permission needed, and any team member who can edit customer data can do it (a Member for the accounts in their own book).
The contact record decides which accounts they see; the grant only decides whether they get in. Every piece of data the portal shows is scoped to the accounts they’re a contact of.
Adding grants needs the manage portals permission (Admin or Builder). Open the portal in Portal Studio, go to Access, and select Add grant. A domain grant such as @acme.com admits every Acme contact, including ones added later, so you rarely have to come back per person. The two Access switches, rules, and the rest are covered in Access & Impersonation.
What a customer experiences
- They open your portal and enter their email address.
- Statisfy emails them a 6-digit code, valid for as long as you set under Settings → Auth (1–60 minutes, default 10).
- They enter the code and land in the portal, signed in and scoped to their account.
One active session per portal, per person. Signing in on a new device ends that contact’s earlier session on the same portal — they’ll be asked to sign in again on the old one.
Contacts on more than one account
A contact can be attached to several accounts — one primary plus any number of secondary associations. If a portal’s template includes the account switcher, that contact sees a picker naming the account they’re viewing and can switch between the accounts they hold; switching re-scopes everything on the page to the account they chose. The switcher only ever offers accounts the contact actually holds — it can’t be used to reach another customer’s data — and a contact on exactly one account sees a plain label rather than a picker.What to check before you invite customers
1
The contact exists
Open the account and confirm the person is listed, with the exact email address they’ll type at sign-in.
2
The email matches
The address on the contact record and the address they enter must be the same. A typo isn’t a distinct error — no code is sent at all (see below).
3
A grant admits them
On the Access tab, select Check an address and enter their email. Admitted means they can sign in; any other answer says what’s missing.
4
Preview as that customer
In Portal Studio, use Preview as on the Preview tab to pick that account and person, and see the portal exactly as they will. This one needs the manage portals permission, since it signs you in as that customer.
Step 5: Preview and Go Live
Taking a portal live is two deliberate moves, so nothing reaches a customer unreviewed:1
Build a preview link
Select Preview link in the editor header. When your draft has edits that aren’t built yet, the popover offers Build a new link from your draft — Statisfy saves your draft, builds it, and deploys it to a preview address; your live site does not change. Builds usually finish in a minute or two, and the popover then shows the link with Copy and Open. Anyone on your team can do this.
2
Go live
When the preview looks right, someone with the manage portals permission — an Admin or Builder — publishes it. The first time, open Settings → Domains → Add domain. Enter a subdomain (lowercase letters, numbers, and hyphens) to serve the portal at
your-subdomain.customer.site, or leave it blank for an auto-generated address — then select Go Live. After that, each new version goes live from Make live… in the editor header.See It the Way Your Customers Do
Once the portal is live, the surest check is to open it as a real customer with impersonation. Nothing about it is simulated — it’s the real portal, on the real URL, with real account data. On the Access tab’s People list, select Open as this user and choose Impersonate user in live site. If the person is a contact on several accounts, pick the one to inspect. The portal opens in a new tab, signed in as that customer, with a Viewing as banner. It needs the manage portals permission. See Impersonating a Customer. What you’re looking at is exactly what a customer on that account sees — their onboarding project, their chat, their data, and nothing from any other account.Who can do what
Building a portal needs no special role — anything that changes what your customers can reach does. Everything that changes what your customers see sits behind one permission — manage portals, held by the Admin and Builder roles. Everything before that is open to your whole team.
So a builder owns a portal end to end: author it, ship it, retire it. Nothing here is admin-only.
Rollback, version history, and archiving are covered in Building & Publishing. To change someone’s role, see the User Management and Roles Guide.
Advanced
Neither of these is needed to get a portal working — add them when you want them.Add a Digital Worker Chat
If your portal includes the Chat or Onboarding component, it needs a Digital Worker to answer your customers. A portal doesn’t come with one — you create the worker separately, then point the component at it.1
Create and configure the worker
Go to Digital Workers, create a worker, and set its persona, knowledge bases, and guardrails. Full reference: Configuring a Digital Worker.
2
Set its status to Active
Only Active workers can serve a portal. A Draft or Archived worker isn’t offered in the picker, and a portal that references one fails to build.
3
Turn on its Portal channel
On the worker’s Portal tab, enable the channel and set the required Acknowledgement message — what a customer sees when a reply is held for human approval.
4
Pick the worker in Portal Studio
Open Settings → Components, choose the worker for the Chat (or Onboarding) component, and select Save changes. Saved settings show in your preview right away and reach the live portal at your next Go live.
The chat picks its own onboarding project. It uses the customer’s most recent project created from a template whose name contains “onboarding” and that still has an open task — not the account’s Onboarding Project field. Point that field at the same project so the chat and the project view are talking about the same work.
Don’t see Digital Workers in your navigation? The nav row needs the Admin role, and the feature has to be turned on for your organization — contact your administrator or Statisfy support.
Brand the Sign-In Email
Out of the box, Statisfy sends a clean built-in sign-in email and your customers can sign in straight away. To send it from your own address instead, that domain has to be verified for sending first.- Go to Settings → DNS, enter your domain, and select Add domain.
- Have your IT or DNS admin publish the generated DKIM and mail-server records at your DNS provider.
- Select Verify in Statisfy. Propagation can take a few hours.
Statisfy rejects a sender address on an unverified domain when you save the login email. A good pattern once verified is
login@your-domain.com.Setup Checklist
Everything that has to be true before a customer signs in
Everything that has to be true before a customer signs in
- A JWT developer key has been generated
- Every Statisfy component in the portal is configured
- An active Digital Worker exists with its Portal channel on (only if the portal has a Chat or Onboarding component)
- Each account’s Onboarding Project field points at the right project (only if the portal shows a project)
- Each customer exists as a person on the account they should see, with the exact email they’ll use
- A grant on the portal’s Access tab admits them, and the Customers switch is on
- Someone with the manage portals permission — an Admin or Builder — is on hand for the go-live (building and previewing need no special role)
- The portal has been previewed and taken live at a subdomain
- A sending domain is verified (only if you want a branded sign-in email)
Troubleshooting
Create portal is disabled
Create portal is disabled
You don’t have a developer key yet — this is the publishable key and JWT secret Statisfy uses to wire a portal to live data. Select Generate key next to the button to create one without leaving the dialog, or generate a JWT secret under Settings → API keys. You only do this once; every portal afterwards reuses the same key. See Publishable Keys & Secrets.
A customer never receives their sign-in code
A customer never receives their sign-in code
Almost always the address isn’t admitted: it isn’t a contact in Statisfy, no grant matches it, the Customers switch is off, or it doesn’t match the contact record exactly. Statisfy answers the sign-in screen the same way in every case and sends nothing — see Step 4. Run Access → Check an address on their exact email; it names what’s missing. If the record is correct, check your spam folder and confirm your sending domain is still verified under Settings → DNS.
A customer signs in but sees an error about not being a customer
A customer signs in but sees an error about not being a customer
Their email resolved to no person on any account — usually because the contact was removed or moved after they last signed in. Re-add them as a contact on the right account.
Go live or Archive won't work for me
Go live or Archive won't work for me
Both need the manage portals permission — the Admin or Builder role. They fail differently, which is worth knowing: Archive simply isn’t offered (the ⋮ menu is hidden on the card, and the Danger zone says you don’t have permission), while Make live… stays clickable and fails with a permission error, so a failure there usually means your role rather than a broken build. Editing and previewing need no special role, which is why the rest of the editor still works. See Who can do what.
A saved sender address is rejected in Settings → Auth
A saved sender address is rejected in Settings → Auth
The address is on a domain that isn’t verified for sending. Verify it under Settings → DNS first — see Brand the Sign-In Email — or leave the sender blank to use the Statisfy default.
The chat area shows a placeholder, or the build fails on a worker
The chat area shows a placeholder, or the build fails on a worker
No worker is chosen for that component, or the chosen worker is no longer Active. Check the worker’s status under Digital Workers, then pick it again under Settings → Components and go live. See Add a Digital Worker Chat.
The portal loads but the project area is empty
The portal loads but the project area is empty
That account’s Onboarding Project field hasn’t been set. Open the account, set the field to the customer’s project, and have the customer sign in again — no rebuild or go-live is needed, because the field is read at sign-in. See Step 3. If this keeps happening for new customers, set up a project template automation so the field is filled in for you.
A component shows a placeholder instead of content on the live portal
A component shows a placeholder instead of content on the live portal
It hasn’t been configured. Open Settings → Components in Portal Studio, set its properties (for example, choose the Digital Worker for a chat), select Save changes, then go live again — component settings reach the live portal only at your next go-live.
Next Steps
- Portals Overview — Lifecycle, statuses, developer keys, and portal addresses
- Creating a Portal — Start a new portal from a template
- Building & Publishing — The editor, versions, going live, and archiving
- Access & Impersonation — Choose who can sign in and open the portal as a customer
- Portal MCP Server — Let Claude edit your portal and deploy a preview
- Configuring a Digital Worker — Create and activate the worker your portal chats with
- Lookup Fields — Set the account’s Onboarding Project field
- Project Template Automations — Create the onboarding project and fill that field automatically
- DNS Setup — Verify a sending domain for the sign-in email
- Publishable Keys & Secrets — Generate and rotate your developer key