Roles and permissions for your team
How the owner, admin, and member roles work, and how to build custom roles that grant exactly the access a team member needs.
Every person on your workspace team holds a role that controls what they can see and do. OrganizeOS ships three built-in roles and lets you build custom roles in between them for anything more specific. Manage roles from Settings, then Access, then Roles.
The built-in roles
- Owner has full access to everything, including billing and the ability to delete the organization. Every organization has at least one owner.
- Admin manages members, content, and most settings, but not billing.
- Member has basic access: they can sign up for actions and see their assignments, but no admin powers.
Owner and admin sit above everything else and can never be handed out through a custom role — only another owner can promote someone to owner or admin.
Custom roles
Between admin and member, you can define custom roles that grant a specific set of permissions instead of an all-or-nothing choice. A permission is a single capability, like viewing contacts, managing email campaigns, or sending SMS to your own assigned contacts, and permissions are grouped by area: people and CRM, outreach, events, actions, fundraising, members, community, volunteers, analytics, and settings.
To create one, go to Roles and select New custom role. Give it a name, then check off the permissions it should carry. You can start from a template to save time:
| Template | What it's meant for |
|---|---|
| Organizer | Manages events, outreach campaigns, and basic CRM |
| Fundraiser | Manages donations, fundraising campaigns, and donor analytics |
| Content Manager | Manages email content and public pages |
| Read Only | Can view everything but cannot make changes |
Pick a template as a starting point and adjust individual permissions from there, or build a role from scratch.
Assigning roles
You assign a role when you invite someone to your team, or change it later from their entry in Settings, then People. A person can only be promoted to a role at or below the level of whoever is assigning it: an admin cannot make someone an owner or another admin.
If you want to hand a subset of your team the ability to assign roles themselves, without giving them full admin, see Departments and delegated admin — departments let you cap exactly which roles a delegated admin can hand out.
Why this matters
Handing out "admin" by default because it's the easy button is how workspaces end up with more people than intended who can see donor data, change settings, or remove team members. Custom roles let you match access to the job: a canvassing lead gets canvassing and CRM permissions without touching billing; a comms volunteer gets email tools without member management. Permission checks happen on the server every time, so hiding a button in the interface is a convenience for people without access, not the actual security boundary — you can trust that a role's limits hold even if someone pokes around outside the normal UI.