Zendesk Account Assumption

Zendesk account assumption is what happens when you raise a ticket and their agent asks to look inside your account. Reasonable request, worth understanding before you say yes.

Start free trial All guides

Two things share the name Zendesk account assumption

Zendesk assuming your users. A setting that lets Zendesk's own customer support staff sign in as a user in your account to investigate a problem you reported. This is what most people mean by account assumption.

Your admins assuming an end user. A separate capability where an admin views the help centre as a specific end user, to reproduce what that person actually sees. Genuinely useful for debugging article visibility and permissions.

They sound alike and they carry different risks. One is vendor access to your data. The other is an internal power that belongs in your role design. Keep them separate in your policy or you will end up writing a rule that covers neither properly.

Why you would let Zendesk in

When the answer to your support ticket depends on your configuration, and it usually does, a Zendesk agent seeing the account beats a Zendesk agent reading your description of it. Diagnosis gets dramatically faster. That's the whole case for it, and it's a good one.

The permission is controlled by an admin in the security area of Admin Center. It's normally granted for a limited window rather than left on permanently, and an admin can turn it off again at any point.

Exact wording and placement shift between interface versions, so find it by looking through the security settings rather than following a screenshot from three years ago. If you can't find it, ask Zendesk where it is in your account. That's a faster route than guessing.

The risk, honestly stated

The risk isn't that Zendesk is untrustworthy. It's that a support session touches real customer conversations, and your obligations to those customers don't pause while a vendor engineer helps you.

Scope. An assumed session sees what the assumed user sees. Assume into an administrator and the session sees essentially everything.

Duration. Access granted "just for now" and never revoked is the standard failure here, and it is the same failure as the API token belonging to somebody who left in 2022.

Your own commitments. Some contracts and some regulators require you to control and record vendor access to customer data. If yours do, an open-ended grant is a finding waiting to be written up.

Sensitive queues. If a brand or group holds health, financial or legal data, decide in advance whether vendor access to it's acceptable. Decide it calmly, not mid-incident at 6pm when you want the problem gone.

Granting and revoking it properly

Five habits, and none of them take long.

Grant it when a specific Zendesk ticket needs it, rather than leaving it on as a standing convenience for a support team you talk to twice a year.

Use the shortest window that lets them work. If the setting offers a duration, set it deliberately. If it does not, put a reminder in your own calendar for the same day.

Note in the Zendesk ticket what you granted and when. Now both sides of the conversation have a record, and yours is the one an auditor will ask for.

Revoke when the investigation closes, and go and look at the toggle rather than assuming it expired quietly on its own.

Then add it to the quarterly audit, next to API tokens, admin accounts and installed apps. Same list, same hour, same person.

That last habit is the one that actually holds. Everything else depends on somebody being conscientious at the end of a stressful investigation, which is exactly when nobody is. A recurring check catches what discipline misses, and it takes about five minutes.

The audit trail, and testing it before you need it

Access changes of this kind belong in the account audit log, and every ticket carries its own event history recording changes regardless of who made them. Between the two you can generally reconstruct what happened during a session.

Generally is doing some work in that sentence, which is why you should test it. Grant access on a low-stakes ticket, then go and look at what actually appears in the audit log. Ten minutes, and afterwards you know exactly what evidence exists rather than what you hope exists.

And if you need to keep that evidence, export it, because audit log retention is finite and the entry you want will be older than the window on the day somebody asks.

FAQ

Frequently asked questions

Can a Zendesk employee impersonate a user in our account?

Only if you allow it. To impersonate a user, Zendesk support needs account assumption switched on, it expires by default, and every action they take is attributed in the audit log.

Should we allow Zendesk to assume users?

Temporarily, while a ticket is open. Zendesk support access via account assumption lets their agent impersonate a user in your account to reproduce a problem, and the setting to allow Zendesk to assume users should be switched off again afterwards.

Can Zendesk employees see our tickets?

Access is governed by the assumption setting in your account and by your contract. Leave it off by default, grant it for specific investigations, and revoke it afterwards rather than relying on it lapsing.

How do I turn off Zendesk account assumption?

An admin changes it in the security settings of Admin Center. Turn it off, then go back and confirm the setting reads as off. Placement varies by interface version, so search the security area rather than following an old screenshot.

Does the permission expire automatically?

It is typically granted for a limited period rather than indefinitely, but verify that for your account instead of assuming. A calendar reminder costs nothing and catches the case where it does not.

What is the difference between Zendesk assuming a user and an admin assuming one?

The first is vendor access to your data during a support investigation. The second is one of your own admins viewing the help centre as an end user to reproduce what they see. Different risks, different policies.

Should we just refuse it entirely?

Usually not. Refusing outright mostly buys you slower resolution of your own tickets. A short, logged, revoked grant gets you the diagnosis without the standing exposure.