Customer Portal & Public Surfaces
Customer portal
Configure the customer portal for login, home, tickets, billing, forums, object views, and custom pages.
Customer portal
Customer portal covers The authenticated customer-facing product for tickets, billing, forum, object views, custom pages, and portal navigation. Use this page when you are configuring the live product surface, planning a rollout, or checking why users see different data from what an administrator sees.
What this surface is
- Primary purpose: The authenticated customer-facing product for tickets, billing, forum, object views, custom pages, and portal navigation.
- Where staff start: Customers sign in to the portal selected for the tenant; staff configure pages and menus from
/settings/pages/customer-portal-menu. - Where admins configure it: Portal-capable objects are configured from object settings and then placed in customer portal menus or custom pages.
- Runtime/detail surface: Portal pages can expose tickets, invoices, forum content, object records, and page-builder experiences to signed-in customers.
- Platform connections: Portal activity uses the same tenant data model but must be filtered by customer ownership and permissions.
Common workflows
| Workflow | What happens | Where to check |
|---|---|---|
| Decide which | Decide which customer audience should log in and what they should be able to see first | Confirm in the product route above before publishing. |
| Enable portal | Enable portal access only for objects and modules that have a clear customer ownership field | Confirm in the product route above before publishing. |
| Configure portal | Configure portal menu items under /settings/pages/customer-portal-menu with labels that match customer language | Confirm in the product route above before publishing. |
| Add pages, | Add pages, object views, ticket entry points, invoices, forum categories, or knowledge content as needed | Confirm in the product route above before publishing. |
Configure it
- Decide which customer audience should log in and what they should be able to see first.
- Enable portal access only for objects and modules that have a clear customer ownership field.
- Configure portal menu items under
/settings/pages/customer-portal-menuwith labels that match customer language. - Add pages, object views, ticket entry points, invoices, forum categories, or knowledge content as needed.
- Check customer login settings, invitation flow, and profile requirements before publishing.
- Test with a real customer-type user and verify they cannot see another customer’s records.
- Review mobile behaviour because many portal users arrive from email or phone links.
- Publish the portal URL only after support, billing, and notification owners know the new flow.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Portal home | Customers need a landing page | Use page settings and menu order. |
| Object views | Customers need their own records | Enable portal exposure on the object. |
| Ticket entry | Customers need support intake and status | Pair with ticket categories. |
| Billing | Customers need invoices or payments | Pair with Billing and payment links. |
| Forum | Customers need community discussion | Pair with Forum module settings. |
| Custom pages | Customers need a tailored experience | Build with Pages and Page Builder. |
Operating notes
- Customer portal is not a public website; use public forms or embedded widgets for anonymous visitors.
- Every portal object should have a clear customer ownership rule.
- Keep portal labels simple because customers do not know internal object names.
- If a portal user sees an empty page, check menu placement, object exposure, ownership filters, and role permissions.
- Portal links in emails should land on a page the customer can access after login.
- Do not expose staff-only notes, internal status fields, or admin-only actions in portal page blocks.
- Use separate pages for high-volume actions such as support tickets and payments.
- Test password reset, invitation, and session timeout before a customer rollout.
- Review portal analytics and support tickets after launch to identify confusing navigation.
- Keep public surfaces and portal surfaces documented separately for security reviews.
For developers
Use the developer and reference pages when this configuration is read or changed by code, scripts, widgets, embeds, API clients, or webhooks.
- /developer/public-access
- /developer/embed-public-forms
- /developer/payment-links
- /reference/system-identity