Seeing what a customer sees

Two tools answer the question "why can this person not do that?", and they are not the same size. Reach for the small one first.

Written for: Reseller, Administrator

Two tools answer the question "why can this person not do that?", and they are not the same size. Reach for the small one first.

	Effective permissions	Sign in as
What it is	A reading of the permission rules	A real session in the customer's name
Changes anything?	No, ever	Yes — whatever you do there, they did
What the customer notices	Nothing at all	Nothing on their screen; two lines in the log
Who may use it	Anybody who can see the member list	Only a membership with the explicit right
Use it when	"What does this role open?"	"It still does not work when they do it"

Effective permissions

People → Users → a person → Effective permissions, the same button in a customer's member panel, or ⌘K → See effective permissions. It also has its own address, so you can send it to a colleague:

https://panel.example.com/permissions?profile=mail
https://panel.example.com/permissions?template=use
https://panel.example.com/permissions?membership=<id>

The page shows three things for the role you pick:

What this role may do — the whole permission vocabulary, area by area. What is ticked, this role carries; what is locked, it does not. The short machine name beside each line (mail.manage, node.config.read) is the word the panel itself uses, so you can search for it.
Which screens open — every destination in the sidebar and in an account's tab bar, with the one operation each of them cannot render without.
Which operations open — every call the panel can make, with the answer this role gets. Refused ones are hidden until you ask for them.

At the bottom the page names where its answers came from: the permission matrix and the column inside it. The page has no opinion of its own. It copies that file, and where the file has no column — a role this version of the panel does not know — it says so instead of guessing.

Somebody who holds two kinds of access at once (a profile on a customer and a rung on a server) gets one tab per kind. There is deliberately no combined answer: the two are decided separately, on different objects, and a single number would be an invention.

Reading it in practice

A customer says their web agency cannot change the DNS. Open the agency member's row, press Effective permissions, and look at the DNS area: See DNS zones is ticked, Change DNS records is locked. They hold Mail management, which sees DNS on purpose and does not change it. Give them DNS management as well, or make the record yourself.

Signing in as somebody

On the account page, the header carries Sign in as; ⌘K offers the same thing while you are on that account, and a person's page offers it per membership. All three ask for a reason before anything happens.

You will only see the action if you are allowed to use it. The right is granted per membership and is off by default — being an administrator is not enough:

$ corecp-panel admin impersonation list
EMAIL              PROFILE     REALM   MEMBERSHIP
axel@example.com   root_admin  corecp  3c1fce17-3b43-4beb-9d36-7cb4e69f1e5f

$ corecp-panel admin impersonation allow support@example.com
audit: admin.impersonation.grant recorded as a paging event (actor root@panel1 (console))
signing in as somebody else is granted to support@example.com (1 membership(s))

The list holds only the people who may; everybody else is simply absent. The right hangs on a staff or reseller membership, never on a customer one.

While a support session is running:

a band across the top of every screen says whose account you are in, who you are, and why you said you were there — plus a frame around the whole window, so it is visible from the corner of your eye on every page;
Back to my own account ends it in one click. It also ends by itself after an hour;
the session may do exactly what the customer may do, and a short list of things nobody may do in somebody else's name: change their password or their second factor, take over ownership, or start a second support session.

What the customer sees of it

On their screen, nothing. There is no notification and no banner on their side.

In writing, everything. Every support session is recorded twice — once under your name and once under theirs — so it appears both in your own activity trail and in the customer's own audit log, with the reason you typed. A customer can read who was in their account and why, at Insights → Audit log.

$ curl -s "https://panel.example.com/api/v1/audit?action=impersonation.start&limit=2" -b jar \
    | jq -r '.[] | "\(.at)  \(.actor_label)  \(.detail.reason)"'
2026-08-24T09:12:04Z  axel@example.com   ticket 4182 — mail is not arriving
2026-08-24T09:12:04Z  anna@test100.nl    ticket 4182 — mail is not arriving

Choosing between them

Use effective permissions when the question is about a rule: what a role opens, why a screen is missing, what changes if you move somebody up a rung. Nothing happens to anybody's account and nothing is logged in their name.

Use sign in as when the question is about a state: they are allowed to do it and it still does not work. Say why in the reason box — it is the sentence the customer will read afterwards — and press Back to my own account the moment you are done.