> ## Documentation Index > Fetch the complete documentation index at: https://docs.inboxmate.psquared.dev/llms.txt > Use this file to discover all available pages before exploring further. # Permissions > Individual rights instead of fixed roles, roles of your own, and actions that always need a human. Until August 2026 a role was a bundle you could not open. "May automate a rule" simply meant "is an Admin" — so anyone who needed to arm one rule was made an Admin, and got user management, mailbox settings and billing along with it. **Settings → Permissions** takes that apart. ## The rights table Rights are the rows, roles are the columns, and every crossing is a checkbox. | Right | What it covers | | ------------------------------- | -------------------------------------------------------------------------------------------- | | **Approve suggestions** | Accept, change or dismiss what the AI proposes in Decisions | | **Automate rules** | Arm a matured rule so it runs without asking | | **Edit shared flows** | Change or delete categorizers shared with the team. Everyone may edit their own private ones | | **Connect mailboxes** | Connect and disconnect mailboxes | | **Manage users** | Invite people, change roles, archive members | | **Change approval requirement** | Edit the list of actions that always need a human (below) | | **Billing** | See and change the subscription | Two rights are deliberately not free to hand out: * **Billing** belongs to the Owner alone. * **Change approval requirement** is Admin and Owner only. A right that loosens a safety lock must not itself be grantable, or a member could be given the right to take the lock off themselves. A lock whose key can be handed around is not a lock. The Owner always holds every right. That is not convenience — it is the one guarantee that stops a workspace locking itself out with nobody able to open it again. **Nothing changes by itself.** The defaults reproduce exactly the behaviour your workspace had before this feature existed. Your people keep what they had until you tick something. A greyed-out checkbox still shows its state. "The Owner always has this" and "this role can never have this" are opposite facts, and both are visible at a glance rather than hidden behind a dash. ## Roles of your own Next to the table, **Add role** creates one — "Accounting", "Reception", whatever your workspace calls it. Then tick what those people need. A new role starts with **no rights at all**. It inherits nothing: a role that quietly arrived with borrowed permissions would be the surprise, not the convenience. You can assign a custom role the same way as a built-in one, both when inviting someone and when editing them later. A role can only be deleted once nobody holds it — move those people first. ## Always needs approval The same page carries a second list: action types that may **never** run unattended, whatever a flow says. Not even if someone sets the step to automatic in the editor, and not even after the trust ramp would otherwise have armed it. Out of the box that is three: | Action | Why | | ---------------------- | ------------------------------------------------ | | **Send email** | The AI writes the text *and* picks the recipient | | **Auto-reply** | Same, answering the sender directly | | **Delete permanently** | Not outbound, but there is nothing to take back | The line is **who wrote it**, not how far it travels. **Forwarding and webhooks are deliberately not on that list.** A forward's recipient and a webhook's URL are typed into the editor by a person; the AI only decides whether the category matches, never where the thing goes. Both therefore mature through the [trust ramp](/user-guide/inbox/ai-maturity) like any other rule. You can still tick them. Anyone who wants every forward or every webhook call reviewed sets the checkbox — that is what the setting is for. Be aware that ticking **webhook** is one-way: a webhook cannot show a preview, so a locked one stays a queue item and the AI-maturity page shows it as *Locked* instead of offering a button that could only fail. ### What happens to rules that already run Before a lock takes effect, InboxMate shows **which running rules it will send back to approval**, and names them. A safety setting that quietly left existing automation running would not be one — but nobody should accidentally sweep away what grew over weeks either. Rules that are sent back keep their history. They return to "waiting for approval"; their earned maturity is not deleted. ## Requesting automation Someone without **Automate rules** still sees the button in AI maturity. Their click becomes a **request** instead of an error. Open requests appear at the top of the same page, with the evidence behind them: who asked, and how many clean approvals the rule already has. Approving one runs through exactly the same checks as arming it directly — including the approval requirement above — so there is no second door with a different answer. Whoever asked sees their own request sitting there too, without the buttons. Otherwise they could not tell whether it had arrived. ## Who can see this page Everyone can read the page: the rules that apply to you should not be a secret. Changing a tick needs **Manage users**, and changing the approval requirement needs its own right on top.