Roles and Permissions That Match Real Jobs

Permission systems tend to grow complicated. Every new feature adds a few new permissions, every special case adds a new role and soon nobody can say with confidence what a particular person is allowed to do. At that point, permissions stop protecting anyone, because administrators grant broad access just to make things work.

We try to keep roles in our platform simple and tied to real responsibilities. Here is how.

A small set of clear roles

Each account has a short list of roles that match how organizations actually work:

• Owner: the person ultimately responsible for the account, including billing and ownership decisions
• Administrator: people who manage the site and its modules day to day
• Member: people who belong to the organization, such as members of a community, who use member features but cannot open the admin area

Each role has a plain-language label and description, so the person adding someone to the account understands what they are granting.

Finer permissions where they help

Some modules need more detail than three roles. A support team might need agents who can answer tickets but not change billing. An accounting module might need someone who can review records but not post entries. In those areas, modules define focused permissions that layer on top of the basic roles, named for what they allow.

We add finer permissions only where a real responsibility calls for them, rather than creating a permission for every button.

Ownership is handled with care

Ownership carries the most responsibility, so changes to it are deliberate. When a new owner is chosen, the previous owner stays on as an administrator rather than losing access entirely, and the change is shown clearly before it is confirmed. An account always has a clear owner.

Adding people is consistent

People are added to an account through one membership process, whether they already have a login or need a new one. Someone who already has an account keeps their password and gains access to the new organization. Someone new gets an account created for them. Either way, the role is chosen at the moment they are added, and the membership is recorded.

Removing access is complete

When someone leaves an organization, removing their membership removes their access to that organization everywhere, because modules share one permission system. Their login may still work for other organizations they belong to, but not for this one. There is no checklist of separate tools to update.

Enforced on the server

Roles and permissions are checked where actions run: pages, actions, interactive components, downloads, background jobs and API requests. Hiding something from a role in the interface is a courtesy; refusing it on the server is the protection. We explain that principle in a hidden button is not security.

People lists respect accounts

Choosing a person for a role, such as an author or an assigned agent, uses a list built from the account's own memberships, never a list of every user on the platform. That detail matters in a platform where one person can belong to several organizations, as described in why we never load every user into a dropdown.

Platform roles are separate from account roles

Our own team's platform roles, such as central administrators who manage the platform as a whole, are separate from the roles inside customer accounts. Being a platform administrator does not make someone a member of every organization, and support access into an account is a separate, recorded action with its own limits, as described in support access done carefully. Keeping the two layers distinct prevents a platform role from quietly becoming access to every customer's data.

Review access regularly

Organizations change. Volunteers come and go, staff change roles and contractors finish projects. We encourage organizations to review who has access periodically, and the account's team list makes that easy: who is there, what role they have and when they were added.

Frequently asked questions

What is role-based access control?

It is a way of managing permissions by assigning people roles, such as owner, administrator or member, where each role allows a defined set of actions.

Can members access the admin area?

No. Members use member features on the website, but the admin area is limited to administrators and owners.

What happens to the old owner when ownership changes?

The previous owner stays on the account as an administrator, so they do not lose access unexpectedly.