Plan requirement
| Subscription | Any plan |
| Access | Admin |
Authentication tells Zendesk who the visitor is, so their history follows them rather than the browser they used.
What changes
- The conversation is tied to a person, not to a browser. They see it on their phone as well as their laptop.
- Agents know who they are talking to, with their tickets and organisation in the context panel.
- History is private. Someone else on the same device does not see it.
- You can restrict what they reach based on who they are.
How it works
Your website, which already knows the visitor is signed in, passes a signed token to the widget. Zendesk verifies it and treats the conversation as belonging to that user.
This is website work rather than a setting, and it needs a developer. The Zendesk side is enabling it and holding the signing key.
Two calls do the work, and these are what you hand over: zE("messenger", "loginUser", ...) signs the visitor in with a JWT, and zE("messenger", "logoutUser") signs them out. The token carries an expiry, so the site has to be able to hand over a fresh one rather than issuing a long-lived token once.
Signing out clears more than the session. On logout, all conversation tags and conversation fields are cleared. If your widget sets those to route or categorise conversations, they have to be set again on the next conversation, so a sign-out in the middle of somebody's visit quietly loses the context your rules depend on.
Check the shorter route first
Where your help centre already authenticates people and the widget is set to use that, messaging adopts the signed-in identity on its own, and the name and email travel with it. That covers a good part of what the token route gives you without a line of code, so establish whether help centre authentication is on before commissioning development.
Three limits worth knowing before you start
- It covers the Web Widget and the mobile SDK, and no other channel.
- It does not apply to your own people: agents and admins are not authenticated this way.
- With multi-conversation messaging a user can be marked authenticated on at most 100 active tickets at once, counting everything not solved or closed.
One design point for whoever writes the token: the external ID is the primary identification, even when an email address is in the token as well. Build the identity around the ID your own system already uses, not around the address.
When it is worth the effort
- Customers already sign in to your site or app. Then it is a small addition with a large benefit.
- Conversations are personal or financial, where history on a shared device is a genuine risk.
- Agents need to know who they are talking to before they can help at all.
When to skip it
A public site where visitors do not have accounts. Authentication there means asking people to sign in before they can ask a question, which loses more than it gains.
Comments
0 comments
Article is closed for comments.