Gated access and the customer portal

A gated Help Center asks visitors to sign in before they can read anything. Article titles and bodies are never served to anonymous visitors or search engines. Gating also unlocks the request portal: Submit a request and My requests.

Turn on gated access

Open Help Desk → Help Center, pick the site, and open the Access step.
Under Who can read it, choose Gated.
Choose how visitors sign in (below).

Gating protects the published pages. It does not change a Note's own access or sensitivity, and it does not give the chat widget any new knowledge.

Email magic link

No setup needed. The visitor enters their email on the sign-in page and receives a secure access link. Following it opens a session bound to this site. Email possession proves the address only; it does not prove the visitor is your customer, so use it when any verified email is acceptable. Link sending is rate limited.

Your customer portal

Under Connect your customer portal you can bind one identity provider so visitors sign in with the login they already have.

A BigCommerce store. Pick this if your customers log into a BigCommerce store. You enter the store hash, the application ID and client ID of your app-level API account, its client secret (stored write-only, never shown again), and the sign-in page on your store. Your developer sets up a small bridge page on the storefront that proves the current login and posts it back to the Help Center.
Another portal (developer setup). Pick this if you run your own portal. You enter a label only your team sees, the token issuer (usually your portal's https address), the audience, a signing secret of at least 32 characters, and the sign-in page on your portal that signs the visitor in and posts the signed handoff back. Handoff tokens are short-lived and single-use.

When a portal provider is bound, email magic links are off for that site. Turn on Also allow email sign-in only if people without a portal account (such as a contractor) should still be able to get in.

A portal sign-in lasts up to 8 hours, and ends after 1 hour of inactivity. Visitors can sign out at any time. Disconnecting the provider ends existing sessions on their next request; the site then falls back to email magic links.

A visitor who signed in through your portal and opens the chat widget arrives already identified. This works only when the widget's Who can this widget answer for is Public knowledge only and the widget has a signing key (see Website chat widget). Your team sees them in the Help Desk as "Signed in through the customer's platform", with the portal's details, such as plan or role, as verified attributes. This carries the sign-in only. It never unlocks internal or Gated knowledge. Content you published for signed-in customers stays available in chat, as it is on the portal's pages.

Submit a request

Signed-in visitors see Submit a request in the header. It is on by default; turn it off with Submit a request form in the Requests card on the Support step.

The form asks for:

Subject, up to 200 characters. As they type it, up to three matching articles appear under "These might answer it", so they can find an answer first.
Category (optional): Question, Something isn't working, Billing, Feature request, Security or privacy, or Other.
Severity, only when you turn it on (below): Normal, High, or Urgent.
Message, up to 5,000 characters.

Sending creates a Help Center ticket in your inbox, with the category (and severity, when there is one) at the top of its opening note. The visitor sees "Request received" with the request number.

In the Help Desk visitor profile, requests and replies from a visitor who signed in through your customer portal show as "Signed in through the customer's platform", with the details their sign-in carried, such as plan or role. Requests and replies from a visitor who signed in with an email link show as "Email confirmed by sign-in link", with no other details.

Severity

Severity lets the visitor set their own ticket's priority, so it is off by default. To show it, turn on Severity field in the Requests card on the Support step. The switch is locked while the request form is off. The form explains each choice:

Normal: "A question, or a problem with a workaround." The ticket stays at Normal priority.
High: "Some work is blocked and there's no workaround." The ticket becomes High priority.
Urgent: "Urgent: work has stopped for many people and there's no workaround." The ticket becomes Urgent.

With the Severity field off, the form shows only Category, and every request starts at Normal priority.

Limits: a visitor can start at most 6 new requests or chats per hour. The form has no file attachments today.

My requests

My requests lists the visitor's own conversations and requests with the customer-facing status (by default In progress, Awaiting your reply, or Resolved; rename them in Ticket Settings → Statuses) and filter tabs for All, Open, Awaiting your reply, and Resolved. Opening one shows the transcript: their messages, the AI's answers, and your team's public replies. Internal notes never appear.

They can reply from the request. A reply on a resolved request reopens it ("Request reopened"). A reply on a closed request opens a follow-up request linked to the original, and they get a link to the new one. Replies are limited to 20 per request per hour.

Links that open the portal

You can link straight into the portal, for example from your own app or emails. Add one of these to the address of any page on a gated site:

?requests=open opens My requests.
?new_request=1 opens Submit a request.
?request=<request id> opens that one request.

They open the dialog for a visitor who is already signed in. The flag is removed from the address bar when the visitor closes the dialog, so a reload does not open it again.

Company-wide view

By default each visitor sees only their own requests. On the Access step, turn on Let verified visitors see their company's requests to add a My requests / My company's switch to the portal. Only visitors with a proven identity qualify: a verified corporate email domain, a verified widget identity, or a portal sign-in. A self-reported email never unlocks a company's list. Colleagues can open and read a request, but only the person who filed it can reply.

Who counts as the company depends on the sign-in.

The sign-in names the visitor's organization. When your portal's signed handoff carries an account id (external_account_id) for the organization the visitor is acting for, the company is everyone who signs in for that same organization. The organization gets a company of its own in Help Desk → Customers (see Customers and companies). The company list holds:

requests filed under that organization: requests sent from the portal and chats started with a signed widget pass that names it, plus their follow-ups, and
older requests that were never filed under any company, from the people in the organization's company. It has none at first (see below).

Requests are filed under the organization only while company visibility is on for at least one of your gated Help Centers. Requests sent while it is off stay unfiled, so turning it on later does not by itself show them to the organization's admins. They stay in each sender's own My requests.

To include older requests from people on the company's email domain, merge the two companies when Help Desk → Customers marks the organization's company as a Possible duplicate (it does when the names match). Or link the organization's company to those tickets from each ticket's customer panel.

Someone who works with several of your customers' organizations files each request under the one they signed in for. A request filed for a different organization than your own company stays with that organization. It never shows in your company list, even when the person who filed it belongs to your company.

The sign-in names no organization. Visitors whose sign-in carries no account id, including everyone who signs in with an email link, keep the earlier rule: requests from people on the same company account, usually matched by corporate email domain.

Your team can link more companies to a ticket in the Help Desk, and each linked company counts. If you add a company, visitors whose sign-in names that company can open the ticket and read its conversation. If customers sign in as that company, the ticket also leaves the requester's own company list. See Customers and companies.

To limit the company list to each customer's owners and admins, also turn on Only admins and owners can see company requests. Then only visitors who signed in through your portal with an owner or admin role in the signed handoff (the company_role claim) see it. Email magic-link sign-ins never unlock the company list under this switch.

Status emails

When a Help Center or chat ticket moves to a pending status or is solved, and when a follow-up is opened, the requester gets an email. The subject and body use the customer-facing status words and can be edited under Ticket Settings → Notifications (Waiting on the customer, Request resolved, Follow-up opened). Emails are suppressed when the customer wrote in the last 10 minutes or the same change was already sent within the hour.

Customers can answer these emails by replying once an admin picks a reply inbox: one of your verified forwarding inboxes, chosen under Ticket Settings → Notifications → Reply Inbox. It is Off by default. Help Center tickets need nothing else. Chat widget tickets also need Email replies to offline visitors on (Settings → Help Desk → Channels).

With a reply inbox, status emails, and emailed copies of your team's replies on widget tickets, use it as the reply address, so an emailed reply lands on the same ticket. The conversation stays where it started: the reply shows in the portal and the Help Desk, and your team answers it as usual. The Waiting on the customer and Follow-up opened emails tell the customer how to answer: "Reply to this email", "Reply from the Help Center portal", or both. If you edit those emails, keep {{reply_hint}} where that sentence goes. The Request resolved email always says to reply to reopen the request. Without a reply inbox, that reply has to come from the portal. See Email inboxes and forwarding and Known issues.