Settings — Client Portal Users
The Settings ▸ Client Portal Users page is the org-wide roster of every external client who has been invited to your organization’s client portal, across all matters. Per-matter access is granted on each matter (in Participants ▸ Clients); this page is the single place to see — and globally suspend — who can sign in to the portal at all.

What you can see
Section titled “What you can see”Each row represents one external portal user:
- Email & name of the client.
- Matters — the count of matters they can reach, with the full matter list on hover.
- Last seen — when they last signed in, or Never if they have not yet logged in.
- Status — Active or Disabled.
Granting access (per matter)
Section titled “Granting access (per matter)”Portal access is granted per matter, not on this page:
- Open the matter and go to Participants ▸ Clients.
- Turn on Client portal access for the matter.
- For each client contact, use the access toggle and set their level:
| Level | Can reach |
|---|---|
| Owner | Matter, billing & approvals |
| Billing | Matter & billing |
| User | Matter only |
A contact becomes a Client Portal User (and appears on this page) once they are granted access on at least one matter.
Sign-in email vs. profile email
Section titled “Sign-in email vs. profile email”The invite is sent to the contact email on the matter — the address you
entered for that client on the matter’s Participants ▸ Clients tab. That is
the address the client signs in with, and it does not have to be the same as
the email on their participant profile: a client can be invited at
personal@example.com while their profile records work@firm.com, or no email
at all.
Every portal sign-in is nonetheless linked to a saved participant profile. That link — not the email address — is what identifies the client everywhere else in Athenty, so the two can diverge safely: changing one never silently attaches the wrong person to a matter, and converting a client request always lands on the right profile (see Client Requests).
For a business or organization client, the invite goes to its authorized representative’s address, and the portal sign-in is linked to the entity — the client you act for — with the representative as the point of contact.
Revoke vs. restore (org-wide kill-switch)
Section titled “Revoke vs. restore (org-wide kill-switch)”This page’s Revoke is an org-wide kill-switch, distinct from per-matter access:
- Revoke immediately signs the client out everywhere and blocks them from logging back in across every matter, until you restore them. Use it when someone should lose all access at once — an engagement ends, or a contact leaves their company.
- Restore re-enables a disabled user; their per-matter access is unchanged from before they were disabled.
Disabling a user does not delete their record or remove them from any matter — it only suspends their ability to sign in. Their per-matter grants are preserved and reactivate on restore.
Permissions and scope
Section titled “Permissions and scope”| Role | View | Manage |
|---|---|---|
| Owner / Admin | ✓ | ✓ (revoke / restore) |
| Member | ✗ | ✗ |
Per-matter access toggles are managed by anyone with edit rights on the matter; the org-wide revoke/restore here is admin-only.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Most likely cause | Fix |
|---|---|---|
| Client can’t sign in | User is Disabled here | Restore them on this page |
| Client signed in but sees no matters | No per-matter access granted | Grant access in the matter’s Participants ▸ Clients tab |
| ”Last seen: Never” | Invite sent but not yet accepted | Resend the portal invite from the matter |
| User missing from this list | No portal access on any matter yet | Grant access on a matter first |
| Converting their request fails with “isn’t linked to a saved participant profile” | Their participant profile was deleted after the invite was sent | Create or open their profile in Participants, add them to a matter as a client with portal access, then convert the request again |
| Converting their request fails with “used by N different client profiles” | This sign-in belongs to an authorized representative who acts for more than one client, so the request is ambiguous | Add the correct client to the target matter first, then convert the request |
| A client contact can’t be invited to the portal | The contact is not linked to a saved participant profile | Link them to a participant profile on the matter’s Participants ▸ Clients tab, then send the invite |
Related pages
Section titled “Related pages”- Settings ▸ Participants Portal — portal-wide configuration
- Matter ▸ Participants ▸ Clients — where per-matter access is granted