> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hired.tools/llms.txt
> Use this file to discover all available pages before exploring further.
# People and invitations
> Three roles, invitations that work before email does, and the hard line between managing accounts and reading content.
Admin lives under **Settings → Admin**, on four tabs: **People** — the roster, the
invitations you have sent and anyone waiting for access — plus **Configuration**,
**Health**, and a **Log** of every administrative change.
## The three roles
| Role | Can do |
| ------------------------- | ----------------------------------------------------------------------------- |
| **Owner** (`SUPER_ADMIN`) | Everything. Created at setup. Cannot be demoted or deleted. One per instance. |
| **Admin** (`ADMIN`) | Invite people, suspend and delete members, configure the instance. |
| **Member** (`MEMBER`) | Their own workspace. Never sees the admin area. |
An admin can only act on members — not on the owner, not on themselves, and not on another
admin. That restriction is what keeps the admin area from being a route to taking over an
instance, and it holds everywhere.
Creating *new* admins is narrower, and not quite uniformly so:
| Route | Who may make someone an admin |
| ----------------------------------------- | -------------------------------------------------------------------------- |
| Inviting a new person as `ADMIN` | The owner only. `admin_invite_user` refuses anyone else. |
| The promote control in **Admin → People** | The owner only. The button is not shown to other admins. |
| `admin_set_user_role` over MCP | Any admin, on any member. It enforces only that an admin acts on a member. |
So an admin connected over MCP can promote a member to admin, where the same admin cannot
do it in the browser. If that matters on your instance, keep admin accounts to people you
would let hold the owner's own connection URL.
**Admins manage accounts, not content.** There is no path — through the app or through
an assistant — from an admin to another person's brain, resumes or applications. Admin
tools return counts of what is in a workspace, never its contents.
[How that is enforced →](/reference/security)
## Inviting someone
**Admin → People → Invitations** → type an email → **Send invite**. They get a link, pick
a password, and land in their own empty workspace. Links stay valid for 14 days. What is
still outstanding is listed under the form, with a link to copy and a control to revoke.
Email is optional. Until Resend is configured, creating an invite gives you a link to send
however you like — nothing is blocked on it.
If [Google sign-in](/self-hosting/google) is configured, an invited person can press
**Continue with Google** instead of choosing a password, and the invitation is accepted the
same way. You do not have to do anything differently to invite them.
By conversation:
> Invite [priya@example.com](mailto:priya@example.com) and write me the message to send her.
That is [`onboard_teammate`](/workflows#invite-and-onboard-someone): it checks whether
email is configured and says so plainly if not, creates the invitation, hands you the
accept URL in full when no email went out, and drafts the message to send.
`admin_list_invites` shows what is outstanding with links and expiry.
`admin_revoke_invite` cancels one so its link stops working.
## When somebody cannot get in
Start with `admin_user_detail`, or click their name in **Admin**. One page carries when
they joined, who invited them, **whether that invitation email actually left**, when they
last signed in, which assistants they have connected and when each last called, whether
they are being billed, how much they have built, every administrative change made to their
account, and anything the instance recorded against their address — a bounced invite, a
tool call that threw.
That one page tells you whether the problem is the account or the email, which decides
what you do next. There is no route from it into their brain, resumes or applications.
### Resetting a password
`admin_reset_user_password` generates a new one and returns it **once**, so you can pass it
on. Every session they had is ended, so an old browser stays logged out.
It cannot be used on the owner, and an admin cannot reset another admin's password. The
reset is written to the audit log; the password itself never is.
### Suspending and deleting
`admin_set_user_active` with `isActive: false` signs the person out everywhere and blocks
both their login and their MCP connections immediately. **Their data is kept.** Setting it
back to true restores everything.
`admin_delete_user` is permanent and removes the account with everything it owns — brain,
resumes, applications. Confirm before calling it.
A suspension is reversible and a deletion is not. When somebody stops paying, or leaves,
or is disputed, suspend. Delete only when somebody asks you to.
## The audit log
**Admin → Log**, or `admin_audit_log`. Newest first: invitations, role changes,
suspensions, deletions, password resets, billing links, and changes to the instance's own
configuration — each with who did it, to whom, and when.
Rows survive the deletion of the account they describe, so "who suspended this person" is
still answerable afterwards.
Narrow it by `group` — `accounts`, `invites`, `passwords`, `billing`, `settings` — and by
`search`, which matches **either side** of a row: the admin who acted, or the account acted
on. Page with `offset`; default 100 entries, maximum 500.
Nothing in it touches anyone's brain, resumes or applications, and a secret is recorded as
having been set, never as its value.
> Who changed the Resend key?
## Per-workspace usage
`admin_instance_stats` gives the shape of the instance: how many people, how many active,
how many invitations outstanding, and how much material exists across all accounts.
Aggregate counts only — never another person's content.