Users & access

Inviting people, impersonating, and removing portal access.

The user list

Everyone who can sign in to a portal, with their organization and side. Search matches name, email or organization name, and you can filter by side or by a specific organization.

The Users page: four activity counts above a table of portal users, each row showing their organization, side, and how long ago they last signed in, sorted with the most recent first. — Most users arrive here automatically from a Zendesk sync rather than being added by hand.

Most users are created by syncing from Zendesk, not added manually. If someone is missing, sync before you reach for an invite.

Last sign-in is the day each person last signed in, and reads Never for an account nobody has used yet — the usual state of a freshly synced user, and the thing to look at before assuming an invite went astray. Click the column heading to sort by it: once for the quietest accounts first, again to reverse, a third time to go back to the usual order. The sort covers everyone your filters match, not just the page you are looking at.

NoteA date marked via impersonation was somebody at Envoy opening the account to support it, not the person themselves — and those visits are left out of the activity counts, so they never inflate how used your portal looks. Sign-in is counted per person rather than per portal, so someone who belongs to two workspaces shows the same date in both.

The four counts above the table — signed in today, this week, quiet 90 days+, never signed in — each filter the list to the people they count. Click one to work through that group, click it again to clear it. They count your whole workspace, not the page you are looking at, and they ignore the search box for the same reason.

TipQuiet 90 days+ and Never signed in answer different questions. The first is people who used the portal and stopped, which is usually worth a conversation; the second is usually an invite that never went out.

The same page with the Never signed in count selected: the list narrowed to three people who have never used the portal, each row offering Send invite, and one showing an invite already pending. — Clicking a count filters the list to the people it counted — and each of those rows offers the one action it needs.

Getting people signed in

Send invite emails the person a link to set their own password. It is good for 72 hours, and while one is outstanding the row shows Invite pending with its expiry. Sending again reissues it — which is the fix when someone lets one lapse, and it stops the previous link working.

NoteThe invite email carries the portal's branding, so recipients see a name they recognize rather than one they do not.

TipSomeone who already has a password does not need an invite — Forgot password on the sign-in page works for them, and does not expire in 72 hours.

NotePassword and magic-link sign-in are always available. Google sign-in can be switched on for your workspace as well, which is an Envoy-side setting — ask, rather than looking for a toggle here.

Administration is not granted here

This page has no roles. Everyone on it is a portal user — someone who signs in to a portal to see their organization's tickets — and nothing you do here grants access to this admin area.

Who may administer the workspace lives on the Members page, one level up from the app, alongside Connections and Account. Add a colleague there, not here. See the next chapter.

CarefulThis is the single most common configuration mistake in VendorApp, in both directions: someone added to Users who expected to administer, and someone added to Members who expected to see tickets in a portal. The two lists do different jobs.

Impersonation

Impersonate starts a session as that user so you can see precisely the portal they see — by far the fastest way to settle a "why can't I see my ticket?" report. A banner shows throughout, and the session ends on its own.

CarefulEvery impersonation is recorded in the audit log against your name. It is a support tool, and it is not private.

NoteThe button only appears for active users who already have a sign-in identity. If it is absent, that person has never been given one — invite them first.

Removing access

Remove revokes this account's access. Their sign-in itself and any other workspace they belong to are untouched, and they can be restored later — tick Include removed to find them again, then Restore access. Removing also cancels any invite they were sent, so an outstanding link cannot let them back in.

Two removals are refused, and each would otherwise leave someone stuck: yourself, since you would lose the page you would need to undo it; and whoever owns the workspace, which has to be transferred on the Members page first.

TipRemoval is reversible, so it is the safe response to someone leaving. You do not need to delete anything in Zendesk to cut off portal access.

NoteRemoved people stay in the list, badged removed, rather than disappearing — history, ownership and the audit trail all still point at them. Nothing here deletes a record.