Skip to main content

​
How end-user identity works

End users are the people who talk to your agents. They never sign in to the admin console. They arrive through a channel — Slack, Teams, the web widget, the hosted chat page, SharePoint — and Cobalt works out who they are so the agent can greet them by name, show them only what they may reach, and act on their behalf when it’s allowed to.

​
The model

Four settings, each in one place:
  1. Settings holds your lists. Settings › Identity › Providers lists your identity providers — the systems your people sign in with, such as Microsoft Entra ID, Google Workspace or Okta. Settings › Identity › Directories lists your directories — the systems Cobalt reads groups from.
  2. Each agent picks one of each. On the agent’s Identity page, the Provider tab picks the provider that checks who people are, and the Directory tab picks where the agent’s groups come from.
  3. Each channel picks how people get in — see The four ways people get in.
  4. Each capability says which groups may reach it. Tools, skills, knowledge and live agent handoff can each be limited to Allowed groups.
An agent serves one population, and its channels are different doors into the same room. That’s why the provider is chosen on the agent, not on each channel. If two groups of people need different providers, they need two agents.

​
The four ways people get in

On a web channel, the How do people get in here? setting offers four choices. Each proves something different about the person. Slack and Teams don’t use these modes. Those platforms already know who the person is, and Cobalt uses that. Email uses the sender’s address. Which modes each surface offers:

​
Only the agent’s provider can vouch for someone

This is the rule everything else follows. On Cobalt sign-in and Provider token, the only thing that can get someone in is being signed in by the provider the agent uses. Nothing else counts:
  • A personal Gmail or personal Microsoft account is turned away.
  • An account from another company is turned away, even if it’s a real Microsoft or Okta account.
  • Being able to receive email at your company’s domain is not enough on its own. What counts is your provider saying the person is one of yours.
People who are turned away see one kind message telling them to sign in with their work account. It never says which provider you use or why exactly they were refused, so nobody can learn your setup by trial and error. See What people see. For Google Workspace, “one of yours” means an account in one of the Workspace domains you list on the provider, because every Google account in the world signs in at the same place. See Google Workspace.

​
Microsoft guest users count as your people

Someone invited into your Microsoft Entra directory as a guest signs in through your directory, so Cobalt treats them as one of your people. If you don’t want a guest to reach an agent, remove them from your directory, or limit the agent’s capabilities to Allowed groups they aren’t in.

​
Choose the agent’s provider and directory

Open the agent, then Identity.
  • Provider asks “Which provider should ‹agent› use to check users’ identities?”. Pick one from your list. None means “This agent doesn’t sign people in.” Choose None only if the agent’s channels are anonymous or use Embedded token.
  • Directory asks “Where do ‹agent›‘s groups come from?”. None means “Capabilities can’t be limited to groups.”
If your list is empty, the tab says so and links to Settings to add one.

​
What changing them affects

Before a change that affects anything, Cobalt shows one confirmation that says how much it affects. Nothing changes until you confirm.
  • Switching the provider changes who can sign in on every channel of that agent: “‹n› channels will ask people to sign in with ‹provider› instead.”
  • Setting the provider to None means those channels stop recognising people. A channel on Cobalt sign-in or Provider token then turns everyone away until you pick a provider again. It never falls back to letting people in anonymously.
  • Switching the directory means capabilities limited to groups from the old directory let nobody in until you pick new groups. See Directories.
If Cobalt can’t work out what a change would affect, it says “Couldn’t check what this changes, so nothing was saved.” and offers only Try again. If a provider or directory an agent uses disappears, the tab keeps showing it, marked Removed, until you pick another. Cobalt normally refuses to remove one that is in use, so this is rare.

​
How long a sign-in lasts

A sign-in doesn’t last forever. When it expires, the person is asked to sign in again, and their conversation is kept. The trade-off to know about: if you disable someone only in your identity provider, they can’t sign in again, but they keep chat access until the sign-in they already have expires, and a chat they already have open keeps working until it’s closed. To end their chat access straight away, also Deprovision them in Cobalt (People sync does this for you when your provider deactivates them). Web chat is then refused on their next message — see Deprovisioning a person. This only affects chat. Admin console sessions work as before.

​
How a person gets resolved

However someone arrives, Cobalt links them to one canonical person — one stable record per real person in your tenant. All history, memory and permission checks hang off that record.
  • Channel identity — a typed identifier that links a person to one channel, such as slack:T01234/U987, teams:<tenant>/<aad-object-id> or email:alice@acme.com. A person gathers several, and someone who uses Slack, Teams and the web chat is still one person, never three.
  • Directory provisioning (SCIM), optional. If you set up People sync (SCIM), Cobalt knows people before they ever message and hears when someone leaves. Where SCIM has linked a person, it stays authoritative.
  • Email claim and release — once an email is linked to a person it’s reserved for them. It can’t silently move to someone else unless an admin, or an authoritative SCIM event, releases it first.
Guests and external users on Slack and Teams — people who aren’t members of your workspace or directory — are told the agent isn’t available to them, and no record is created for them.

​
The person record

Every canonical person has a page (open it from a conversation or the directory) with two tabs:
  • Identities — every channel identity linked to them. From here you can link a provisional identity manually (email links go through the claim guard), unlink one (it reverts to provisional — nothing is deleted), or release an email address so a different person can claim it.
  • Authorized systems — the per-user integration authorizations they’ve granted (each integration, its scopes, when it was authorized and when it expires). Revoke one and the next time the agent needs that system for them, they’re simply asked to authorize again.

​
Deprovisioning a person

When someone leaves, Deprovision on their page retires them in one step: Cobalt previews exactly what will happen — how many channel identities will be deactivated, integration authorizations revoked, and email addresses released — and asks you to type a confirmation before proceeding. The cascade is all-or-nothing: if any step fails, no changes are applied and you can retry. Revocations at the external vendors complete asynchronously; the page shows a notice until they’re done. A deprovisioned person is refused on their next message, on every surface — Slack, Teams and web chat, including a chat they already have open — in the same way as anyone else who isn’t one of your people. Signing in again doesn’t get them back in, and doesn’t create a new person for them. (SCIM-managed tenants rarely need to do this by hand — a deactivation in your provider does the same thing automatically.)

​
How an integration presents to the external system

When the agent acts on an external system, one of two things is true, and the integration decides which — an administrator does not choose it:
  • A shared account — every person’s requests run under one credential. That system’s own audit log shows the shared account, not the person who asked.
  • Each person’s own sign-in — the agent uses the individual’s OAuth authorization for that system. Its audit log shows them, and the agent can only do what they already can.
The integration’s page states which one applies, in a sentence, read-only.

​
Privileged actions require an established identity

A privileged tool — one that acts with the admin credentials on an integration rather than as the person asking — will not run for someone Cobalt cannot identify. Established means the person arrived through Slack, Teams, SCIM, Cobalt sign-in, Provider token or Embedded token. An anonymous visitor on a public widget is refused; the end-user tools on the same integration keep working for them normally. Two more things follow from that:
  • A deprovisioned person is refused immediately. The check reads your directory’s current state on every call, so an account you disable through SCIM stops being able to drive privileged actions on the next attempt — there is no cached grant to wait out.
  • The agent never asks the person to authorize anything. Privileged tools run on credentials an admin already connected, so there is no sign-in or connect-an-account step for an end user to complete. If you ever see the agent suggest one on a privileged action, that is a bug worth reporting.
Which of your people may use a given tool — privileged or not — is set with Allowed groups.