Building a role
A role is a set of resources and what may be done to each. Grant what the job needs and nothing more.
📷 Screenshot placeholder — Team → Roles → New role, the permission grid.
A role is a named set of permissions you give to a seat on your team. Access is granted per resource, and each grant carries its own actions. The grid is long because the console is large — work area by area rather than row by row, and grant what the job needs and nothing more.
What a role is
Each grant names a resource — projects, tasks, entries, claims, bonus offers, boosters, revenue, withdrawals, fees, commissions, billing, the forum boards, farmers, influencers, join requests, recruitment, the team itself, alerts, settings and reports — and which of create, read, update, delete the role may do to it.
The grid groups them into five areas: Community, Money, Projects, People and This business unit. Rather than start blank, pick Start from to copy a built-in role's grants and adjust from there. A role needs a name that is unique in your business unit and at least one grant.
Create, update and delete include read
You cannot act on what you cannot see, so any write action implies read. Ticking Delete alone is not possible: the form lists the row under Fix before saving until read is on, and the server adds read to any write grant it receives anyway.
Scope narrows, never widens
Access is narrowed in two places:
- On the grant. A grant on a project resource — projects, tasks, entries, claims, bonus offers, boosters, farmers, influencers, join requests, recruitment — can be limited to one project. A grant on a forum resource can be limited to one board. Money and business-unit resources are not scoped.
- On the seat. When you invite or edit a member you can give the seat a project scope. It applies to every grant in their role and limits every page they touch — farmers, entries, forum threads — to that project. When both are set, the seat's scope is the one that counts.
A role can also be pinned to a project. The pin is recorded on the role, shown on every seat that holds it, and hides the per-grant pickers in the grid. What the server enforces is the seat's scope, so when you invite someone with a pinned role, give the seat the same project as its scope.
📷 Screenshot placeholder — the invite panel with Project scope set to one project.
Marketplace purchases
Marketplace purchases, under Money, lets a team member buy NFTs on the marketplace for the business. Give it only to people trusted to spend from the business wallet.
Built-in roles
Four roles come with the platform. Owner is the system role: full control, never assignable. Admin covers projects, people and this business unit, with read access to billing, and is the one built-in you can edit. Community and Finance are locked — to change one, duplicate it and edit the copy. The copy is a custom role like any other.
Inviting a member
Invite by email from the Team page, choosing a role and, if needed, a project scope. The link is valid for seven days; the person accepts by signing in with that same email. Your team covers invites, seats and removing members.
The Owner
The account that created the business unit is the Owner. Its seat cannot have its role changed or be removed, and the Owner role cannot be assigned or offered to anyone else. Owners and admins pass every permission check — roles limit the members you invite.
The one grant to treat with care
Team & roles lets a member invite, remove and re-role other members — including changing their own role. Nothing in the platform stops a member with that grant from widening their own access; the form warns you when you tick it. Give it only to people you would trust with an Owner invite.