> ## Documentation Index > Fetch the complete documentation index at: https://docs.goosybear.ai/llms.txt > Use this file to discover all available pages before exploring further. # People and roles > Inviting people to your account, the four roles and what each one may do, the per-person permissions you can turn on, and the gates that apply whatever the role. People are invited into your **account** and hold a role there. This page is about who can do what — and about the four things nobody does without a person saying yes, whatever role they hold. Everything below lives under **Settings → Account**, in the **Members** section. The rail row **Members & invites** goes straight to it. ## The four roles | Role | What it is | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Owner** | The account holder. Everything an admin can do, plus closing the account and handing ownership on. There is exactly one owner. | | **Admin** | Full management: people, connections, settings, plan and billing. Only the owner can make someone an admin, and an admin cannot close the account or transfer ownership. | | **Member** | The working role. Makes things, publishes what is approved, works inside the spending boundary. | | **Client** | The guest role. Sees the work shared with them and does none of the making. A client can be given the ability to approve — that is what a [client sign-off](/how-approvals-work) rests on — but nothing beyond it. | **Roles decide what someone may do. Approval gates decide what has a consequence.** Both apply at once, and the second one is not softened by the first — see [How approvals work](/how-approvals-work). ## Inviting someone **Invite by email** in the Members section. Enter their address and choose whether they come in as a **member** or an **admin**; the screen states the difference beside the choice. You then get a confirmation step naming the person and the role before anything is sent. **Admin** is offered to whoever is looking, but only the owner can actually grant it. An admin who chooses it is told to ask the owner to make the change. They do not need an account with us yet — accepting the invitation creates one. Seats are unlimited on every plan, so inviting the whole team costs nothing extra. ## Reading the members list One table answers "who is on this account?", and an invited person who has not accepted yet is part of that answer, so both appear in it. | Column | What it tells you | | --------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Person** | Name and email. Yours is marked *(you)*. | | **Role** | Their role. For people you can manage, this is a dropdown. | | **Status** | **active** once they have accepted, **invited** while an invitation is out, **expired** when an invitation has run out. | | **Since** | When they joined, or when the invitation was sent. | | **Permissions** | The per-person switches below. | An invitation that has not been taken up has its own menu: **resend** or **revoke**. Both are confirmed first, because both are one-way — a resend replaces the link the person is holding with a new one, so the old link stops working. ## Changing someone's role Use the dropdown in their row. It offers **Member** and **Admin** — though **Admin** only takes if you are the owner. An admin who picks it gets the same refusal as on an invitation: only the account owner can make someone an admin. Ownership is not in that list, because it moves by its own deliberate step: open the row menu for an active admin and choose to transfer ownership. You are asked to type the account name to confirm, and the warning on that dialog is the important part — **only the new owner can transfer it back**. You cannot undo it yourself. ## Per-person permissions Some things can be turned on for one person without changing their role. Today there are two switches, one per row: * **Configure automations** — letting that person set up work that runs on its own. * **Manage connections** — letting them connect, reconnect and disconnect the channels the workspace publishes to. Owners and admins hold both already, so the switches matter for members. The column header says *more controls soon*, and it means it: this list grows. A switch you turn on takes effect on that person's next action. Nobody has to sign out and back in. If you cannot manage a row, the same information is shown as plain text — **On** or **Off** — so you can see what someone holds without being able to change it. ## What a role never buys Four things stop for a person no matter who is asking: * publishing something * spending money or credits * deleting something * granting or changing access An owner holds every permission there is and still meets all four. Permission answers *may this person do this at all?*; approval answers *has someone said yes to this specific thing?* They are enforced separately and both have to pass. The same is true of programmatic access: a key carries the permissions of the person who made it, resolved fresh on every call, and never more. See [Who can use the API](/permissions). ## Two-factor for everyone **Settings → Account** has a **Security** section with one switch: require two-factor sign-in for everyone on the account. It is off to begin with, which means two-factor is each person's own choice on their profile. Turn it on and everyone here — including you — sets up an authenticator app the next time they open Goosy Bear, and cannot use it until they have. ## The record The **Activity** section at the foot of the same page lists recent changes to people, billing, publishing and security, newest first — who did what, and when. Permission changes and ownership transfers both appear there, so nobody has to remember who was given what.