How I solved a customer’s permission issue using an impersonation feature. Why it’s a high-risk, high-reward tool, the safeguards I use, and how granular permissions make it safer for B2B customers.

Post Outline

The customer issue that sparked the idea
Why impersonation is a powerful tool for support
The security risks involved
My safeguards and role limitations
Why granular permissions matter for B2B
Balancing usability with safety

Building an Impersonation Feature Without Compromising Security

The Issue That Sparked It

A customer reported they couldn’t perform an action in the app. On my end, everything worked fine, which made it confusing to debug. It turned out to be a permission issue that wasn’t being surfaced in the UI.

The Power of Impersonation

Because I had built an impersonation feature before, I could view the app exactly as the customer would—without them sharing their password. This saved time and avoided back-and-forth explanations.

The Security Risks

The impersonation feature is powerful but risky. You wouldn’t want unauthorized people to use it. That’s why I’ve restricted it as an admin-only feature, with the possibility for future support team use under strict controls.

Safeguards in Place

Even with access, users can’t impersonate admins. Currently, there are only three roles: Fleet Manager, Technician, and Admin (which is just me). This keeps the feature under tight control.

Why Granular Permissions Matter

Instead of creating a new role for each customer’s needs, I use atomic permissions for every action in the app. Teams or sub-teams can be assigned only the permissions they require, reflecting the actual structure of the customer’s organization.

Balancing Usability and Safety

The impersonation feature is a classic high-risk, high-reward tool. With the right safeguards, it can dramatically improve support efficiency without compromising security.

When customer issues aren’t what they seem Sometimes a support ticket isn’t about a bug—it’s about perspective.