Team and permissions

Forumulate's permissions are built from a single vocabulary of capabilities — small, named things a person can do ("Invite and remove members", "Write docs", "Moderate the forum"). Roles are bundles of capabilities. You invite people, give them a role, and — when you need finer control — build your own roles, scope a grant to a single space, or grant a role to a whole group.

This guide covers inviting teammates and how the role model works.

Inviting a teammate

Go to your organization's Members page (/o/<org-id>/members). You need the "Invite and remove members" capability (built-in Admins and Owners have it).

To invite someone, enter their email, choose a role from the dropdown, and send the invite. Forumulate emails them a link to accept.

A few things happen behind that:

• The invite link expires after a set number of days.

• Staff roles (anything above Member/Guest) use a seat on your plan.

• You can only grant a role whose capabilities you hold yourself — you cannot hand out more access than you have. Granting Owner additionally requires the ability to transfer ownership.

Accepting an invite

The invitee clicks the link in the email, which opens the Accept invite page with the token filled in. If they do not have an account yet, they register first; the invite is matched to their verified email. An invite also shows up in the invitee's own Invitations to you list at the top of their Members page, so it is not lost if the email is.

Managing pending invites

Pending invites appear in their own section on the Members page — each with the email, the role, and the expiry — with a Revoke button. Revoking deletes the invite so the emailed link stops working.

Managing members

The member list shows everyone in your organization. Each row has:

• The member's name and email.

• A role dropdown to change their role inline.

• A View as option (act as that member) if you have the impersonation capability.

• A Remove button.

A member who has been banned (a DENY grant, below) shows a "banned" badge. The sole Owner of an organization cannot be demoted or removed — there must always be an owner.

The built-in roles

There are seven built-in roles, from most to least privileged. Each is a fixed bundle of capabilities:

• Owner — everything, including deleting the organization and transferring ownership.

• Admin — manages the organization and every surface (members, roles, billing, SSO, settings, integrations, spaces, and all content), but not org deletion or ownership transfer.

• Maintainer — curates the knowledge base: writes and publishes docs, and moderates the forum (because promoting a solved thread into docs is both).

• Editor — owns the blog: writes and publishes posts, and takes part in the community like any member.

• Moderator — a member who can also moderate the forum.

• Member — reads everything, and posts and votes in the forum.

• Guest — read-only.

You can see the full capability matrix — roles against capabilities — on the Roles page (/o/<org-id>/roles).

The names the API uses

The console shows the labels above; the API takes and returns the uppercase key. There are seven and only seven, and nothing else is a role:

curl -sS -A 'my-app/1.0' -H "Authorization: Bearer $TOKEN" \
  -X PATCH -H 'content-type: application/json' -d '{"role": "MAINTAINER"}' \
  https://forumulate.com/api/orgs/$ORG/members/$USER_ID

An earlier version of this page named roles that do not exist in that enum, so a reader built a request around a value the API refuses. A custom role is not one of these: it is referenced by its own id, and a grant carries either a built-in value or a custom role id, never both.

Custom roles

When the seven built-ins do not fit, build your own. On the Roles page, the custom-roles manager lets you type a name and check exactly the capabilities the role should carry — grouped by area (organization, spaces, docs, forum, blog) and labelled in plain language. A custom role can never grant an unknown capability; every one comes from the same canonical list.

When a member holds a custom role, its checked capabilities replace the built-in role's set for that grant.

If you delete a custom role, anyone who had it falls back to their base built-in role rather than losing access unpredictably.

Per-space grants and inheritance

A grant can be org-wide or scoped to one space. Org-wide grants cascade into every space; a space-scoped grant adds on top for that space only. This is how you give someone edit rights to just one space without making them an org-wide editor.

The resolver combines all of a person's grants with one firm rule: deny always wins.

1. An org-wide DENY blocks the capability everywhere — it is how you ban someone from the whole organization.

2. A space-scoped DENY blocks it in that space.

3. Otherwise, the capability is allowed if any grant — org or space — carries it.

4. For someone with no grant on a space: a private space is invisible to them, while a public space gives them Guest (read-only) access.

A space ALLOW can never override an org DENY.

Groups

You can grant a role to a whole group rather than person by person. Create groups on the Groups page (/o/<org-id>/groups) and add members to them. Then, on the Roles page, the group-grants manager lets you pick a group, a role, and a scope — the whole organization or a specific space. For example, give the "Docs Team" group edit access to one space.

A role granted to a group counts exactly like a role granted to each member directly, and a group grant can also carry a custom role and a per-space scope.

Where each control lives

What's next

• Publishing and domains — making spaces public.

• Getting started — the signup and setup flow.