Pages

Pages gives your workspace a public home for documents, ticket intake, customer threads, and booking links.

You can use a Bnder subdomain such as company.bnder.page or, with Pro, a custom domain you own.

Branding

Each domain can have its own:

  • Display name and logo
  • Primary and secondary colors
  • Background and text colors
  • Background image
  • Light or dark color preset

The branding is also used by public documents, ticket pages, ticket email, and the browser favicon where applicable.

Public language and entry point

Choose the language used for Bnder buttons, messages, forms, and page metadata. Content written by your workspace, such as document text, project names, ticket fields, and status labels, is shown as written and is not translated automatically.

Choose what visitors see when they open the bare domain:

  • Public documents
  • New ticket

You can also choose a default project. If that project is no longer public, visitors return to the available project selection.

Domain limits

Bnder subdomain and custom-domain capacity depends on paid seats. Custom domains require Pro. The Pages settings screen shows the workspace's current capacity and usage.

Create a Bnder subdomain

You need the Manage settings permission.

  1. Open Workspace Settings → Pages.
  2. Select Create Page.
  3. Choose Bnder subdomain.
  4. Enter the subdomain and display name.
  5. Configure branding, public language, entry point, and optional default project.
  6. Select Create.

If a name is already used or the workspace reached its limit, choose another name or free a domain slot.

Connect a custom domain

You need Pro, Manage settings, and access to your DNS provider.

  1. Open Workspace Settings → Pages.
  2. Select Create Page, then Custom domain.
  3. Enter the hostname and display name.
  4. Configure branding, language, and entry point.
  5. Add the DNS records shown by Bnder.
  6. Wait for ownership and SSL checks to complete.

DNS changes can take up to 48 hours. Do not use the domain for customer links until it is marked active.

Tickets on Pages

Ticket emails use the project's selected Pages domain and branding when available. Public ticket creation, secure ticket threads, customer login, and unsubscribe pages also run on Pages.

See Ticket Setup and Public Ticket Portal.

Booking links use paths on your Pages domain and share its branding.

See Booking Links and Create Booking Links.

Authenticated CRM portals

Workspace administrators with Manage CRM schema can compose an external portal from CRM records, tickets, forms, commitments, outcomes, customer check-ins, and communication preferences. Each component must be enabled separately. Settings show only actions supported by that section: permitted record fields can be updated, commitments can be fulfilled, and communication preferences can be managed. Ticket and form submission stays inside their dedicated customer workflows.

External contacts sign in through the existing passwordless customer portal. They see only their matching CRM Person records and Records linked through a portal-visible relationship. Record Types, fields, activities, forms, and reviews must also be marked portal-visible or published. Connected commerce or external status data is never shared automatically.

One email address must resolve to one active CRM Person. If duplicate active People share the signed-in address, Bnder blocks CRM portal access before loading any relationships. An administrator must merge the duplicates or remove the shared email; archived and already-merged source records are ignored.

Portal cards use the names configured in your CRM data model. Statuses, select options, linked records, Outcomes, and Commitments appear by their readable names rather than internal IDs. Published review details are shown as labeled values; technical IDs and raw JSON are not shown to customers.

Configured customer-visible fields are shown even when customers cannot edit them. When Update fields is enabled, customers get controls suited to each field, including choices, checkboxes, long text, dates, currency, contact details, and permitted CRM relationships. Externally managed and calculated values remain read-only.

To publish a safe portal:

  1. Configure the relevant CRM fields, Record Types, relationships, forms, and activities for portal visibility.
  2. Open the CRM portal configuration and add only the required components. One section opens at a time so its summary remains visible without a long stack of controls. Search by name to select available Record Types, customer-visible fields, and portal forms; internal IDs are not required.
  3. Select the Pages domains that may show the portal. The sticky action bar keeps Preview and Save changes available while you configure sections. Use Preview to open the customer sign-in on the selected domain before sharing it.
  4. Grant only the additional actions the section offers, such as Update fields, Fulfill commitment, or Manage preferences. Viewing is automatically granted when a section is enabled.
  5. Enable the portal and test with an external contact account.

The signed-in portal starts with actionable counts for shared forms, promises, and results. Section navigation becomes a compact selector on phones so content stays reachable without a horizontally clipped menu. Tickets and forms include a route back to the portal.

Long sections load in small pages. Select Load more at the end of a section to continue. Pages containing only unavailable or filtered entries are skipped automatically; a loading or retry message appears only in that section, so the rest of the portal remains usable.

Required fields stay neutral until the customer leaves a field or tries to submit it. The portal then marks the exact field and explains what needs fixing. Save actions remain disabled until values change, unsaved changes are guarded, and each customer action reports its own progress and result.

Disabling the portal or a component fails closed immediately. Existing customer portal sessions cannot bypass the configured component, entity, field, or action allowlists.

Sessions and usage

A session counts when a visitor opens a public Pages experience. Viewing multiple documents in the same visit does not create a session for every document. Secure ticket thread refreshes are excluded.

Current hourly and monthly usage appears in Workspace Settings → Pages and Plans & Seats. If the limit is reached, visitors see an explanatory message until capacity becomes available again.