# Roles and permissions

> Who can do what in a workspace, and how to check your app gets it right.

Permissions are the difference between a tool people trust and one they are nervous about. There are two separate sets of rules to think about.

## Workspace roles

Workspace roles decide what your colleagues can do in Automo Build: who manages billing and members, who builds and publishes, and who only looks. The exact roles available are shown when you invite someone or change a member's access.

A few principles that hold whatever the role names:

- Keep the people who control billing and deletion to a small number.
- Give builders access to the projects they work on.
- Give reviewers and stakeholders read-only access where possible.

For larger organisations, SSO, SAML and SCIM, RBAC and an audit stream are available. See [Security](https://automo.build/security) on the website.

## Your app's own users

Workspace roles decide what your colleagues can do. Your app's users have their own rules, set inside the app, usually per account or per record. Do not confuse the two. See [User accounts and sign-in](/connect/user-accounts).

## Checking it works

Rules that are only enforced in the interface are not enforced. To check properly:

1. Use a second account with the role you want to test.
2. Try the forbidden action directly: open the settings address by hand, submit a form you should not see, load another person's record.
3. If it works, the rule needs tightening. Ask for it in one sentence.

[Security scanning](/build/security-scanning) runs access-control probes too, but your own check is still worth doing.

> [!warning] Before publishing, test the visitor path. Most permission bugs are found by a signed-out browser, not by reading the code.

## Changing a role

Change a member's role from the workspace's member settings. Reduce access as soon as someone no longer needs it.

Next: [Sharing a project](/collaborate/sharing-a-project).