Skip to main content
After you create a portal, you customize it in Portal Studio — the in-browser editor — preview your work, and take it live when it’s ready. This guide covers the editor, drafts and versions, previewing, going live, and managing your portals.

​
Prerequisites

​
Portal Studio

Open a portal from the Portals page at app.statisfy.com/portals to open it in Portal Studio. The editor is organized into five tabs: Portal Studio with the Preview, Code, Versions and Settings tabs, the Draft saved indicator, and the Preview link and Make live controls, above a draft preview rendering the portal's onboarding view Your edits are saved automatically as a draft shortly after you stop typing. The editor header shows Saving draft… while it saves and Draft saved once it’s done. Drafts are kept separate from the live version, so:
  • You can leave and come back later, and your in-progress work is still there.
  • The live version your customers see does not change until you go live.

​
Previewing Your Work (Preview tab)

The Preview tab renders your draft live as you edit — it’s labeled Draft preview and updates to reflect your latest changes. You can:
  • Switch the preview between Desktop, Tablet, and Mobile to check how your portal looks on different screens.
  • Refresh the preview if you want to reload it.
  • Use Preview as to pick a specific account (and person) and see the live, account-specific data your customers would see when signed in. Nothing you do in the preview is written.
  • Use the ⋮ menu next to Preview as to impersonate that person: open a real signed-in session as them on the preview URL or the live site. See Impersonating a Customer.

​
Editing Code (Code tab)

The Code tab shows your portal’s files in a tree alongside an editor. A problems bar under the editor reports compile issues as you type — when everything is valid you’ll see No problems — preview compiles cleanly. Use Split preview to view your changes next to the code. The Code tab: the portal's file tree beside the editor, with the "No problems — preview compiles cleanly" status bar Portals are built with React and TypeScript. A small set of packages is ready to use right away — there’s nothing to install:
  • React — for creating your pages and components.
  • Statisfy packages — anything that starts with @statisfy/, such as ready-made components for showing customer data, the Digital Worker chat, and the customer sign-in screen.
These are the only packages you can import. For anything else, you’re free to write your own code and components — you just can’t import other outside libraries. This keeps portals lightweight and quick to load. Image and other asset files appear in the file tree too; they open in a read-only viewer (you can View source for SVGs).
Your portal’s main page file (index.html) is set up and managed for you. You don’t need to create or change it — just build your content in the src folder.

​
Configuring Components (Settings tab)

Some of the ready-made Statisfy components you can drop into a portal — like the Digital Worker chat or the onboarding project module — need to be told which Digital Worker or data they should use before they’ll work. You set that in Settings → Configuration → Components, without touching code.
A Statisfy component you haven’t configured shows a placeholder instead of its content — for example, “This chat isn’t configured yet — set its Worker in the portal’s Settings.” Choose its Worker here to make it live.
The Components panel has two views:
  • Draft — the settings you’re editing. These are what your draft Preview uses.
  • Live — a read-only look at the settings your published portal is using right now. Use Copy to draft to pull a live value back into your draft.
For each component, set its properties one of two ways:
  • Set a value — type or pick a fixed value (for example, choose a Digital Worker from the list).
  • From a field — bind the value to an account field, so it resolves per customer when they sign in.
Some properties are Locked by Statisfy and shown read-only — you don’t need to set these. Shared values apply to every component that uses them. Unlike code edits, component settings are not autosaved — select Save changes when you’re done. Saved settings show in your preview right away; they reach your live portal at your next Go live, together with your code — so a banner reminds you when your draft settings differ from what’s live.
Editing component settings needs permission to manage portals. Without it, the Components panel is read-only.

​
Every configurable component needs a configId

Settings can only configure a component that names itself in code. Each config-driven Statisfy component must carry a literal configId prop — <DigitalWorkerChat configId="support" /> — and that id is what the Components panel shows as the instance’s slot:
  • A component with no configId, or one built from a variable (configId={id}), fails the save and build. It has to be a plain string in the source.
  • Two components sharing a configId intentionally share one set of settings.
  • Don’t pass an identity prop such as workerId next to a configId — the SDK ignores it and the save gate rejects it, so the value can’t silently diverge from what Settings shows.
See Config mode and Portal Runtime Config for the code side.

​
Where the onboarding module gets its project

The onboarding module doesn’t take a project id — it resolves one per signed-in customer from an account field. That field is the Onboarding Project field on the Account (onboarding_project__c_), a system lookup field pointing at a project, provisioned automatically — you never create it. In Settings → Configuration → Components it appears as the shared, Locked property “Onboarding project source”: read-only, because re-pointing it would change onboarding for every portal at once. What you do control is the value per account:
  • Set each account’s Onboarding Project field to that customer’s project (on the account record, or in bulk via import, the API, or field automation).
  • An account with the field empty resolves to no project, and the module renders its empty/not-configured state rather than another customer’s data.
A portal reads the resolved value through GET /sdk/v1/config/portal — see Portal SDK: Project API.

​
Exposing account and people fields (Settings tab)

Portals can’t read or edit any account or contact data by default. Settings → Configuration → Account fields and Settings → Configuration → People fields control exactly which fields a portal can use:
  • Account fields apply to the signed-in customer’s account.
  • People fields apply to the signed-in contact.
Each list shows only the fields the portal can use. A field that isn’t listed is hidden from the portal, and every field starts hidden.
  • Add field opens a searchable list of the fields you can still add. A new field starts at Read.
  • Each listed field has a Read | Edit toggle:
  • The ✕ next to a field removes it from the portal (it becomes hidden again). It doesn’t change the field anywhere else in Statisfy.
Only the levels a field supports are offered:
  • Fields with a type portals can’t show yet aren’t offered in Add field. If one is already listed, it shows Not supported in portals — remove it.
  • Edit is offered only for fields that are editable in the app. Custom fields must also be user-created and not AI fields. Fields that can only be read show Read only in portals, and their Edit option is unavailable.
  • A contact’s email and account associations can be read but never edited from a portal.
Use Search fields to find a listed field, then select Save. Like component settings, field access isn’t autosaved. Unlike component settings, a saved change applies right away to both your preview and your live portal. You don’t need to go live again.
A section with unsaved edits is marked Unsaved, and a dot appears next to Configuration (or Sign-in) in the Settings menu, so you can tell what still needs a Save before you leave.
Statisfy re-checks each field on every request. A field that’s deleted, changes type, or stops being editable drops out on its own.
Saving field access needs the manage portals permission (admins and builders). Without it, the controls are read-only and show “You don’t have permission to change field access.”
Exposed fields reach your portal two ways:
  • In code — through GET/PATCH /sdk/v1/account and GET/PATCH /sdk/v1/me. See the API Reference.
  • In component settings — a From a field binding ($field) resolves only while its account field is exposed. A $field that names a hidden field shows as a problem in Settings → Configuration → Components and fails the save. Locked properties, such as the onboarding project source, always resolve.

​
Saving Versions

Autosave keeps your latest work as a Working draft, shown at the top of the Versions tab with the files you’ve changed. When you reach a milestone you want to keep, the draft row gives you two ways to record it:
  • Save as version — Record a named checkpoint, nothing more. A saved-only version has no preview URL and can’t go live until it’s built.
  • Build preview — Record the checkpoint and build it. The version gets its own preview URL, and that same build is what goes live.
Each saved version shows a build status — Building…, Deployed, Saved · no preview (saved but never built), or Build failed — and the version currently serving your customers is badged Live. Others are marked Older than live or Newer than live so you can see where each one sits. Selecting a version shows its details and its preview URL if it has one; if a build failed, the error is shown so you can fix it and rebuild. Saving a version doesn’t change your live site on its own — see Going Live below.
A preview URL is a real sign-in surface: a customer can enter their email, receive the one-time code, and land on the portal signed in — even before you’ve published the portal for the first time. The session it mints is pinned to the specific preview build the URL serves, so you can walk a real customer through a brand-new portal end to end before you take it live. Preview URLs are unlisted rather than private, so share them only with people who should see unreleased work.
The Versions tab: a Working draft entry above a saved version badged Live, with that version's preview URL, its Deployed badge, and the Currently live control

​
Customizing the Login Email

When a customer signs in to your portal, Statisfy emails them a one-time sign-in code. Settings → Sign-in lets you tailor that email to match your brand — who it comes from, its subject, and its full HTML body.
Only people allowed to sign in receive a code. The address must match a contact on an account and be admitted by the portal’s Access settings (or be a teammate while Your team is on). An unrecognized address gets no email and no error message — the screen looks identical either way, so that the portal can’t be used to probe who your customers are. If a customer says the code never arrived, use Access → Check an address on their exact email before looking at deliverability.
You can set:
  • Sender email — the “From” address customers see. It must be on one of your verified sending domains; an address on an unverified domain is rejected when you save. A good pattern is login@your-domain.com.
  • Sender name — the display name shown next to the address (for example, your company name).
  • Subject — the email’s subject line.
  • Code expires after (minutes) — how long a sign-in code stays valid (1–60, default 10). This sets both the {{expiry_minutes}} value shown in the email and the code’s real lifetime, so the email never misstates when the code stops working.
  • Email body (HTML) — the full HTML of the message.

​
Placeholders

Use these tokens anywhere in the subject or body — Statisfy fills them in when it sends each email: Include {{otp_code}} somewhere in the body so customers can see their code — for example:

​
Send a test

Enter any email address and select Send preview to receive a sample of the login email (with a placeholder code) using your currently saved template — so you can see exactly what customers will get.
You don’t have to customize this email. If you leave it as is, Statisfy sends a clean built-in default, so customer sign-in works out of the box.

​
Previewing and Going Live

Taking a portal live is a two-step flow, so you can review your changes at a real URL before any customer sees them:
  1. Build a preview link. Select Preview link in the editor header. The popover names what the current link contains; when your draft has edits that aren’t built yet, select Build a new link from your draft to save your draft, build it, and deploy it to a preview address. Nothing is copied automatically — use Copy for the link, or Open to view it. This does not change your live site.
  2. Go live. When the preview looks right, select Make live… in the editor header and confirm — the confirmation names the exact version, for example Make 558fc88 live, the address it publishes to, and which version it replaces — or that it’s your first go-live. Promoting an older version is labelled as a rollback and tells you which version stops serving. Statisfy promotes that deployed version to your live, customer-facing site, and the portal’s status changes from Draft to Live. This step needs the manage portals permission (admins and builders). Make live… stays clickable for everyone, so without the permission it fails with a permission error rather than being hidden — you’ll need someone who has it to publish for you.
Making a version live doesn’t rebuild anything — it publishes the same build you previewed. That’s why Make live… only offers a version that already has a preview build; for anything else, build a preview first. Builds usually finish within a minute or two. A published portal open at its URL, showing the customer sign-in screen where visitors enter their email for a one-time code
A preview deploy is for your review only — going live is always a separate, deliberate step. Your customers only ever see the version you’ve taken live.
A preview URL is public. It isn’t behind your Statisfy login: anyone who has the link can open the preview and see whatever the page renders without signing in. It’s an unlisted address, not a private one — share preview links only with people who should see unreleased work, and don’t put anything in a preview you wouldn’t publish.
If a preview deploy or go-live doesn’t finish, you’ll see a message that it failed or timed out. Try again; if it keeps failing, contact support@statisfy.com.

​
Choosing Your Portal’s Address

Under Settings → Domain, you manage every address your portal is served at. A portal can have three kinds of address: Adding and removing addresses needs the manage portals permission (admins and builders).

​
Permanent address

Statisfy gives every portal a permanent address automatically. Statisfy generates it from the portal’s name plus a short random suffix, for example onboarding-3f9a2c.customer.site. In Settings → Domain it’s labeled Permanent address with a lock icon.
  • You can’t remove the permanent address. Statisfy rejects a removal attempt with “The portal’s permanent address cannot be removed.”
  • No other portal can claim it.
  • It stays with the portal when you unpublish or archive it. When you publish again, the portal comes back at the same address.
  • Your own domains point at it. It’s the target of the routing record described below.

​
Adding a subdomain

Select Add domain and enter a subdomain. Your portal is then served on Statisfy’s managed portal domain, which in production is customer.site, so acme becomes acme.customer.site. Leave it blank to use the permanent address. Subdomains use lowercase letters, numbers, and hyphens (up to 63 characters). The domain shown next to the field is appended automatically.
Live portals and previews sit on different domains: a live portal is served at <subdomain>.customer.site, while preview builds stay on statisfy.app. The suffix shown in the dialog is always the authoritative one for your environment.

​
Using your own domain

You can serve a portal at a subdomain of a domain your company owns, such as portal.acme.com. Statisfy issues and renews the TLS certificate for you. Prerequisites
  • The manage portals permission.
  • Access to edit DNS records for your domain at your DNS provider.
Set up your domain
  1. In Settings → Domain, select Use your own domain.
  2. Enter the hostname, for example portal.acme.com, and select Continue. The hostname must be a subdomain. Statisfy rejects bare domains such as acme.com, IP addresses, and hostnames under Statisfy’s own portal domains.
  3. The dialog shows two CNAME records. Add both at your DNS provider, copying each Name and Value exactly:
    • 1. Proof of ownership. Its name starts with _acme-challenge.. It proves you control the domain so Statisfy can issue a certificate.
    • 2. Send traffic to this portal. Its name is your hostname and its value is the portal’s permanent address.
  4. Select Verify.
For example, for portal.acme.com the records look like this:
Keep the proof-of-ownership record in place after the domain is live. Statisfy needs it to renew your certificate.
Verify results Each time you select Verify, the dialog shows where setup stands: The dialog can also show:
  • A routing warning. “We cannot see the routing record yet. The domain will not load until it points to …” means the routing record is missing or doesn’t point at the portal’s permanent address yet. Ownership and the certificate can still progress, but visitors can’t reach the portal at your domain until you fix the routing record.
  • A CAA hint. While the certificate is issuing, the dialog notes: “If this stays pending, check that no CAA record on your domain blocks pki.goog.” If your domain has CAA records, make sure they allow pki.goog to issue certificates.
Finish setup later You can close the dialog at any point. A domain that isn’t live yet stays in the Domains list with a Set up button. Select it to reopen the dialog with the same DNS records and select Verify again. Statisfy checks domains that aren’t live yet every hour:
  • Once you’ve selected Verify and Statisfy has started issuing the certificate, Statisfy activates the domain as soon as the certificate is ready. You don’t need to select Verify again.
  • If a domain isn’t live within 72 hours of being added, Statisfy expires it. Statisfy removes the domain from the portal and releases the hostname. To try again, add the domain again with Use your own domain.
A hostname can only belong to one portal. If it’s already in use, Statisfy shows “This domain is already in use.”

​
Rolling Back to a Previous Version

If you need to undo a change after going live, open the Versions tab, select an earlier built version, and choose Make live. Statisfy re-publishes that version to your live site. The version that’s currently live is shown as Current live.

​
Managing Portals

  • Open a portal — On the Portals page, select its card to return to Portal Studio.
  • Rename a portal — In Portal Studio, select the portal’s name in the header, type the new name, and press Enter (or Esc to cancel). Renaming needs the manage portals permission and changes only the display name; the portal’s addresses are unaffected.
  • Archive a portal — Use the ⋮ (more) menu on a portal card and choose Archive, or open Settings → Danger zone in the editor and select Archive portal, then confirm. Archiving needs the manage portals permission (admins and builders); without it the Archive action isn’t shown.
The Settings tab scrolled to its lower half: the portal's Components, the Domains section, and the Danger zone with the Archive portal control What archiving does
  • An archived portal that’s still live keeps appearing in the list — in both views, and with an Archived badge — so you can notice it and unpublish it if that wasn’t intended. One that was also unpublished drops out of the list entirely, since there’s nothing left to manage.
  • An archived portal can’t be edited — saving, previewing, and going live are all blocked. The editor will tell you the portal is archived if you try.
  • The git history and built versions are kept, so nothing is destroyed — but Portal Studio has no un-archive action. Recovering an archived portal means contacting support@statisfy.com.
Unpublishing while you archive If the portal is live, the archive dialog offers Also unpublish this portal. Archiving alone leaves the live site serving (so customers aren’t interrupted by accident); tick this box to also take it offline:
  • It clears the live pointer and stops serving the portal at all of its addresses.
  • It removes the portal’s subdomains so they free up for reuse, and releases its custom domains.
  • The portal keeps its permanent address. If you publish again, the portal comes back at that address.
  • This is recorded in your audit trail.
  • It can’t be undone automatically — you’d publish the portal again to bring it back online.
A live portal that’s archived without unpublishing keeps serving at its URL. The Archived badge in the list is there so you can notice and unpublish it if that wasn’t intended.

​
Next Steps