Multiple portals per app
Run more than one customer-facing portal off the same backend — useful when you have distinct user groups (customers, partners, suppliers) that need their own login, permissions, branding, and source code, but share the same data.
What each portal owns vs. shares
Per-portal (independent)
- • Users table — who can log in
- • Permissions / data filters — what each user sees
- • Branding (theme, logo)
- • Login & SSO configuration
- • Public URL / custom domain & SSL
- • Portal source code (pages, components)
- • End-user analytics
Shared across portals
- • Tables & fields (the database schema)
- • Records (the actual data)
- • Connectors & data syncs
- • Workspace members (the people building the app)
- • Billing & subscription
- • Admin internal interface
Single-portal apps stay unchanged
Most apps only need one portal. You still get a portal tab in the center navigation bar (labeled with the portal's name), but there's no extra chrome beyond that — the AI agent treats “the portal” as unambiguous.
When a second portal exists, each portal gets its own tab in that same navigation strip. URLs gain a portal segment so each portal's Admin, Users, and preview views are deep-linkable independently.
The “active portal” concept
At any moment one portal is your active portal. The highlighted portal tab in the navigation bar, the Users tab, the Publish dialog, and Portal Settings all operate on it. Your choice persists across reloads (per workspace member, per app).
URLs follow: /{app}/portals/{portalSlug}/{portal|preview|users|publish}
The legacy URLs (/{app}/portal, /{app}/users, etc.) keep working for single-portal apps and resolve to your active portal in multi-portal apps.
Talking to the AI agent
The agent always knows which portals exist and which one you're currently looking at. Ask “in the partner portal, add a contracts page” and it will switch to that portal first, then make the change.
Mutations (file edits, settings changes) always target the active portal, so the model can't accidentally edit a portal you're not looking at without switching you to it first.
For read-only inspection (e.g. “does the customer portal have a similar page?”) the agent can peek at sibling portals without switching.
Creating a new portal
- Open Setup in the center navigation, then the Portals tab.
- Click New portal.
- Give the portal a name and slug. Optionally pick a portal to copy from.
- On create, the portal gets its own URL, theme, and source code. The shared backend (tables, records, connectors) is unchanged.
Things to know
Multi-portal is gated by a workspace feature flag (multiPortal) for staged rollout. Workspaces without the flag still see a tab per portal when they have multiple portals (e.g. created earlier), but the Setup → Portals tab and “New portal” action are hidden until the flag is on.
Each portal needs a unique slug within the app and a unique publicSlug globally. The create dialog handles slug auto-generation; the server enforces uniqueness.
End-user accounts are per-portal — logging into the customer portal does not also log you into the partner portal even with the same email.