Roles and permissions

A role is a named set of permissions. A permission is one thing a person is allowed to do, like editing customers or issuing a refund. You give a role to a team member, and they can do whatever that role's permissions allow.

Permissions are specific

Each permission covers one action on one kind of thing: view a customer, void an invoice, create a refund, manage the catalog, change settings. This lets you draw the line exactly where you want it. Someone can be allowed to record payments but not to issue refunds, or to read everything but change nothing.

Roles bundle them up

You rarely hand out single permissions. Instead you build a role, a named bundle like "Support agent" or "Finance", that holds the permissions that job needs. Then you give the role to the people who do that job. When the job's needs change, you change the role once, and everyone with it is updated.

You can create your own roles with whatever mix of permissions fits how your team works.

The owner

The owner role is special: it is the top of the organization and holds full access. Every organization has exactly one owner. Everyone else has a role you assign.

Where else roles matter

Permissions do more than gate the app's buttons. A workflow that takes a sensitive action, like applying a credit or cancelling a subscription, can only be built by someone whose role holds that permission. A person cannot automate something they are not allowed to do by hand.

Edge cases

• A role is a bundle; a permission is one action. You assign roles, not individual permissions.
• Custom roles are yours to shape. Build the mix of permissions your team needs.
• The owner always has full access and cannot be locked out.