What Is the Customer Portal?
Before this capability, a customer company’s conversations with you lived wherever each individual employee’s email inbox happened to keep them — scattered, personal, and invisible to a colleague who might need to see the same thread. The Customer Portal gives a customer company one shared, signed-in place to read and answer those conversations instead. It’s a separate surface from your team’s inbox: portal visitors don’t see your workspace, and your agents don’t operate inside the portal — it’s a window a customer company’s own people sign into, showing them their company’s conversations with you.
The governing rule behind everything the portal does is simple: a portal visitor sees exactly what they’d already see in their own email client, and nothing more. The portal doesn’t add tenant-internal visibility a customer wouldn’t otherwise have; it consolidates visibility a customer’s employees would already have separately, each in their own inbox, into one shared place.
What the portal is (and isn’t)
- It’s a signed-in customer-facing surface, reached at an address of yours — a hostname you add under Settings → Custom Domains, where the portal sits beside your knowledge base and your status page, or the address we host for you. It is not a feature inside your agent inbox.
- The people who sign in are the contacts linked to a customer organization in CRM. There is no separate list of portal people to maintain: whoever is on the company’s contact list can sign in, and you change who gets in by changing the company’s contacts.
- They can view and reply, within the limits below.
- Alongside people, a company can be given a portal API key so its own systems can read the same conversations. You issue and revoke those keys; the customer doesn’t create them.
- It deliberately does not show internal notes, side conversations, or anything else that’s tenant-internal. If a customer wouldn’t see it forwarded to their own inbox, they don’t see it in the portal.
- A reply sent from the portal isn’t a portal-branded outbound email — it’s treated as an inbound customer message, exactly as if the customer had replied by email. The only email the portal itself originates is the sign-in code.
Turning it on: two switches, not one
The portal ships behind the customer-portal feature flag, seeded as beta and off by default, so it is not available in every workspace. Once the flag is on for your account, turning the portal on is a two-step gate:
- Your whole account — the master switch on Settings → Customer Portal. This is also where you choose the inbox a portal-started conversation is bound to, the sign-in page headline and logo, and what a newly enabled company inherits.
- Each customer organization — the switch on the Portal tab of that organization in CRM. This one is per company.
Both switches start off, so nothing changes for your account or for any of your customer organizations until someone deliberately opts them in. You can have the portal on in general while most of your customer organizations still have no portal access at all — turning the account-level switch on doesn’t itself open the door for anyone.
Turning a switch off doesn’t just block new sign-ins — it revokes the affected sessions at that moment. Turning off the account-wide switch signs out every portal person in the workspace; turning off one company’s switch signs out that company’s people. A portal session otherwise lasts 30 days and is extended on every request, so without that revocation, turning the portal back on later would have quietly readmitted everyone who was signed in when it was turned off — including whoever prompted you to turn it off in the first place.
Visibility: their own, or the whole company
Each organization’s visibility is one of two levels, and everyone at that company gets the same one:
- Their own, and the ones they are copied on — the conversations that person is the requester of, plus the ones their address is on the CC line of. This is deliberately not “only the ones they started”: a conversation you’re copied on is already in your mailbox, and the mail client the portal mirrors draws no line between the two.
- Every conversation their company has — every conversation belonging to any contact linked to that organization, plus anything they’re copied on.
The setting lives on the organization, and each person inherits it. There is no per-person override, no hold-out flag for one individual, and no domain-matching mode: a contact linked to the organization can sign in whatever their email domain is, and someone you don’t want in the portal is removed by unlinking them from the organization in CRM. Leaving the organization’s setting blank makes it inherit your account-wide default instead.
The one override that does exist sits on a portal API key, and it only goes one way: a key’s own visibility and reply setting can restrict what its organization allows, never widen it. A key set wider than its company is clamped back down to the company’s level.
Access isn’t cached on the person or the session — it’s re-resolved from the live settings on every request. The session is just proof of who signed in; it carries no permissions of its own, so a change to someone’s access — their contact link, their company’s settings, or your account-wide switch — takes effect on their very next request rather than waiting for them to sign in again.
The reply setting
Separately from visibility, each organization is set to Read only or Read and reply.
This setting covers exactly one case: a conversation the person was never part of, which they can see only because the company’s visibility is set to the whole company. Anything already in their own mailbox — the conversations they’re the requester of, and the ones they’re copied on — they can answer whatever this says, because they could answer it from their mail client and no setting of yours could stop them.
Where the setting does bite:
- On a conversation they were never part of, Read only means the portal offers no composer and the API refuses a reply, so going straight to a compose URL doesn’t work around it.
- Starting a new conversation from the portal always requires Read and reply, and it also requires that you’ve bound an inbox — either by choosing one on Settings → Customer Portal, or by having exactly one active email inbox for us to fall back to. If your chosen inbox stops working, the portal refuses rather than silently sending from an address that has no inbound routing.
A reply from the portal is written as the customer’s own inbound message. It does not run through your Agent Stack. It fires automations, engagement and SLA the way any inbound message does, and then stops — so the same customer who would get an automatic AI answer by email waits for a human when they reply in the portal. That’s deliberate, not an oversight.
Signing in: a one-time emailed code
There’s no password for a portal account. A person enters their email address and receives a six-digit code, then types that code into the portal. The code expires in five minutes, is single-use, and allows three wrong attempts before it stops working. It’s a code, not a magic link — there is nothing to click.
The code is sent from your own verified sending domain, the same way any other email of yours goes out. If you have no active sending domain, no code can be sent at all.
Only the newest unexpired, unused code for an address is honoured; requesting a fresh code supersedes any earlier one, so an old or undeliverable code can never shadow the one someone is actually holding. The sign-in page answers identically whether or not an address can use the portal, so it can’t be used to find out who your customers are.
What conversations look like in the portal
The portal has only three words for a conversation’s state — Open, Awaiting your reply, and Closed — and “Solved” is not one of them, because nothing in the data proves a conversation is solved.
Your team’s internal lifecycle state is never shown as it stands. An archived conversation reads as Closed. Anything your agents haven’t marked done reads as Open. Only once a conversation is marked done does the portal compare who actually spoke last — and it measures that on messages the customer can genuinely see, so a reply that never went out doesn’t count. If your side spoke last, the customer sees Awaiting your reply; if they spoke last, or if the two are tied, or if your side has said nothing visible at all, it stays Open rather than telling a customer the ball is in their court when it isn’t.
A conversation started from inside the portal is created the same way a conversation started by email would be — there’s no separate “portal” channel type; portal-originated conversations are email conversations, and your answer goes out by email to the requester and every CC.
What the portal deliberately never shows
Consistent with the governing rule above, the portal filters out:
- Internal notes — anything written for your team, not the customer. System messages and transcripts go with them.
- Side conversations and internal comments — anything that isn’t the customer-facing exchange itself.
- Anything not yet actually delivered — a reply that’s still queued or sending, or one that was suppressed (for example, because a human took over from the AI before it went out), isn’t shown. Only messages that reached sent, delivered or read are shown as something you “said,” because a customer would never see a message their own mail server hadn’t yet delivered either. What the customer wrote is theirs whatever its delivery state.
- Attachments on a withheld message — a file is offered only when the message carrying it is one the portal would show, and the download link enforces the same rule rather than trusting the list.
- Conversations you’ve hidden — an agent can hide an individual conversation from the portal, and a hidden one disappears from it. Spam, merged conversations, simulation runs, and anything that isn’t an email conversation are excluded too.
One consequence worth planning for: because the portal originates no mail of its own, a colleague who never signs in doesn’t see a portal message at the moment it’s sent. They see it when your team replies. The portal is where it’s meant to be read.
In short: if you’d be comfortable with a customer’s own inbox showing it, the portal can show it too. If you wouldn’t, the portal doesn’t.