[dtertman]

> if possible, disable user notifications/emails when an account is being impersonated — or remind staff that impersonating a user will still generate emails, notifications, and dashboard events.

Never, ever disable notifications. Notifications are the only way the user has to cross-check that the agent actually did the thing they were supposed to do, and only that thing.

I worked for a large benefits outsourcing corporation. We had impersonation, and we had a way for agents to cancel notification. A few agents realized they could change a participant address, get a 401k loan, and then cancel the notifications for those things. They used these combined capabilities to steal from our participants.

[martell]

> Never, ever disable notifications. Notifications are the only way the user has to cross-check that the agent actually did the thing they were supposed to do, and only that thing.

Disagree here, when the user is not aware of the impersonation disabling things like notifications and the ability of the admin to interact with notifications is the correct thing to do so that the admin does not dismiss other notification on behalf of the user or spam the user from activity the user didn't do themselves. The user could think that their account has been hijacked by an external actor which creates it's own set of trust problems for the user with your product. (I would however, leave them enabled on a non production environment; for testing purposes)

> I worked for a large benefits outsourcing corporation. We had impersonation, and we had a way for agents to cancel notification. A few agents realized they could change a participant address, get a 401k loan, and then cancel the notifications for those things. They used these combined capabilities to steal from our participants.

This sounds like a failure from the product and development team who designed and implemented this system. If you are tracking the impersonation correctly it should be easy to see internally that the user didn't change the address or request a 401k loan themselves and a system should be in place to ensure that such changes get flagged and reviewed.

Impersonation should generally only be used in 3 situations.

1. With a user to reproduce a problem they are having. (In this case leaving notifications enabled should be fine) Though you can use an external integration like inspectlet to (and look at logs) replay user sessions.

2. As read only impersonation to ensure the user world view is correct. (This stops you from testing/navigating everything because some times you need to POST or PUT to get to certain frontend pages or reproduce other user behaviour) It is still very useful though in most cases.

3. A write impersonation on a non production environment (staging/devtest/locally). You can dump production data into one of those to test deeper on the frontend.

In general, some kind of admin panel/support system should be used to do write changes to a users account but lets say you need to do writes on production with impersonations like your example above.

It is generally support staff that is using this feature to write on behalf of the users (developers generally have access to way more and have all other kinds of tools and knowledge at their disposal to manipulate user data)

I always wondered why support systems show staff members user details like the last 4 digits of a SSN instead of hiding that information and having the support member enter in the digits the user gives them to validate and unlock more functionality like your situation above for the duration of the call. This way the admins/support staff can not randomly decide to act on behalf of users, they are also generally going to be on a recorded call so it is easy to ascertain if the user actually needed the impersonation support. This means that the review backlog from the flagged activities is minimal and easy for another isolated team to go through/ heck you could even train some ai models to do that part for you with some voice transcription.

[dtertman]

> when the user is not aware of the impersonation

I'm curious, so please don't assume ill intent. What's a valid use-case where an event would be 1) done by an impersonator, 2) not driven by the person being impersonated, and 3) produce a notification that should be squelched?

Your three use cases don't seem to lead me to those situations: In the first one, you agree that notifications are OK. I agree with that.

In the second one, it's read-only, and so I wouldn't expect notifications to be produced. If there are notifications about read-only aspects (your account was accessed, e.g.), I suppose I'd be OK with them being suppressed, but I think I'd still lean towards a custom notification (your account was accessed by an administrator, e.g.).

In the third one, shouldn't you scrub your data while you dump it? Everywhere I've ever worked that didn't scrub their data (i.e. set all of the email addresses to [e-mail]) eventually regretted it.

[dtertman]

> If you are tracking the impersonation correctly it should be easy to see internally that the user didn't change the address or request a 401k loan themselves and a system should be in place to ensure that such changes get flagged and reviewed.

Inbound voice is notoriously difficult to establish metrics on. You generally have to review the calls. The HRO company has (literally) millions of participants, and so keeping up with the call volume from all of them is a challenge.