Just to reiterate the impersonation flow as I understand it from your docs in a nutshell, I create service users in each tenant that each of our project admins can impersonate. Then I create a flow that allows users with a project level impersonation flow to impersonate those specific users?

No, that's not quite right. You don't need to create separate service users in each tenant for impersonation The actual flow is simpler: 1. Your project admins authenticate as themselves (they're real users in your project) 2. They have the

Impersonate

permission assigned at the project level 3. When they need to access a specific tenant, they impersonate an existing client user who belongs to that tenant The impersonation flow requires an input field for the

Impersonated User

login ID. Your admin would enter the login ID of any actual client user in the target tenant. Example flow: • Admin logs in as themselves • Admin enters a client user's login ID (e.g.,

<mailto:client@tenant-a.com|client@tenant-a.com>

) • The

User / Impersonate

action validates the admin has the

Impersonate

permission • Admin now has a session as that client user, with full access to that tenant's context The session JWT will show the impersonated user's ID in the

sub

claim and the impersonator's ID in the

act.sub

claim. You're not creating dummy/service users - you're impersonating real client users to see exactly what they see and troubleshoot in their context.