Identity

Customer SSO

Customer SSO lets a customer organization sign its own people in to the help center through its identity provider. You do not configure their provider, you supervise a fleet of connections that the organizations configure themselves. This is an Enterprise feature. (For your own agents, see Agent SSO.)

Two sides, two owners

The work is split on purpose, because at a few hundred organizations you cannot be the directory administrator for every customer.

You supervise from Settings, Customer SSO: a global delegation switch and a monitored fleet of connections.
They configure from the portal, under My organization: a contact who holds the Organization admin grant connects the provider and verifies the organization's domains.

You hold neither the customer's secrets nor the mandate to change them, so the supervision screen is read-only per connection: the only action it offers is to disable a connection, never to edit it.

Turn on delegation

The delegation switch at the top of the screen decides whether customer organizations may configure their own SSO at all. When it is on, any contact who holds the Organization admin grant sees the SSO and Domains screens in the portal. That grant is given by an agent from the organization's record, or by an organization admin who already has it.

Domain discovery

A contact never picks a provider. They enter their email address; the domain is matched against the organization's verified domains, and a verified domain that carries an active connection is what routes that person to their organization's provider. Everything hinges on the domain being verified first.

Today the portal sign-in screen sends a magic link for every address. The automatic redirect to the organization's provider is not wired yet, so domain verification below is the part of this feature that is fully live.

Verify a domain

In the portal, under My organization then Domains, an organization admin adds a domain. Consumer domains such as gmail.com or outlook.com are refused, the format is checked, and a domain can belong to only one organization in the workspace. Open HelpDesk then shows a TXT record to publish on that domain's DNS zone.

ohd-verify=<token>

Once the record is published, "Verify now" runs a real DNS TXT lookup. On a match the domain flips to Verified and its failure counter resets; on a miss it is marked Failed, the failure counter goes up, and a "record not found" note appears. A verified domain belongs to exactly one organization.

You cannot attach SSO to a domain that has not been verified, and a domain another organization has already verified is blocked. This is the guard against account hijacking, and there is no way around it: proof of DNS ownership comes first, always.

Monitor connections

The supervision screen opens on four counters: active connections, connections pending verification, connections in error, and secrets expiring within 30 days. A counter turns its accent colour when it is not zero.

Below them, a dense table lists every organization that has a connection or a verified domain: a health dot, the organization, its domains, the protocol and provider, the status (Active, Pending, Error, Disabled or No SSO), the member count and the customer-side admin. You can search by organization or domain and filter by All, Error, Pending or No SSO. Selecting a row opens a read-only drawer with the status and any error reason, the protocol and provider, the covered domains with their verification state, the customer admin, failures over the last 24 hours, the masked client secret and its expiry, and the last successful sign-in. The drawer's one action is to disable the connection.

When a connection fails

A Needs attention block collects everything actionable: a connection in error (with the number of failed attempts over the last 24 hours), a domain still unverified or failed, or pending for more than a week, and a secret expiring within 30 days. Each row carries a Notify admin link that opens an email to the customer-side administrator, because your part is to prompt, not to fix. When a connection needs to be stopped, you disable it from the drawer; the customer re-verifies the domain or updates the connection on their side.

The design calls for a connection to be suspended automatically after repeated failed checks, but the code does not enforce that yet: a failed check marks the domain Failed and raises it under Needs attention, and stopping a connection is a manual step from the console. Because the live sign-in exchange is not wired yet, the Active and Error states and the 24-hour failure counts are read from stored connection state and the sign-in event log rather than from a running provider exchange.