Permissions

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. 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. 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: 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 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.