Prev Next Access levels in Cirrus are set by **role type**. Every custom site role is connected to one of four role types, and the role type controls how much power that role has over other users. Use this article to understand the hierarchy of role types and the rules for who can manage whom.
## The four role types
Cirrus has four built-in role types, ordered from most to least permission:
1. **System admin**
2. **Admin**
3. **Author**
4. **Candidate**
When you create a new site role under **Admin > Roles**, you connect it to one of these four. The connection is what determines the role's authority over other users.
The default for a new custom role is **Candidate** (the lowest). You can change a custom role's type up or down at any time.
## Rules for managing other users
The role type sets hard limits on what a user can do to other users, regardless of the rest of the role's permissions:
- A user **cannot change the settings or role of someone with a higher role type**. Admins cannot change System Admins.
- A user **cannot add users with a higher role type**. An Admin cannot create a System Admin.
- A user **cannot promote themselves**. An Admin cannot raise themselves to System Admin. They can create other Admins within their hierarchies, but only a System Admin can grant new Admins the permission to start creating users in specific hierarchies.
System Admins are set as administrators in the root hierarchy and every other hierarchy at tenant creation. From there it is the customer's responsibility to customise and maintain.
## Admins versus group / deputy admins
A role type alone is not enough for user management. An Admin also needs **hierarchy-level permissions** that say which groups of users they can manage.
System Admins can deputise user management for a group within the hierarchy tree:
1. Open **Admin > Users > [user] > Hierarchies**.
2. Tick the **Administrator** checkbox next to each hierarchy the user should manage.
After this:
- The user can add and manage users from that hierarchy level **and below**.
- Only System Admins can change the Administrator checkboxes. Admins, Authors, and Candidates can view them (if their role allows access to Admin > Users) but cannot tick or untick them.
### Example
John is added as an Administrator to "Test centre 2" by a System Admin. The tree looks like this:
- Test centre 1
- **Test centre 2**
- **Group 1**
- **Group 2**
John can manage users in the bold hierarchies (Test centre 2 and below). He can view users from Test centre 2 down. He can edit and delete users in his hierarchies, but not in Test centre 1.
Because John is an Admin (not a System Admin), he cannot:
- Promote himself to System Admin.
- Create new System Admins.
He can:
- Create new Admins inside Test centre 2 and below.
- See the Administrator checkboxes on user profiles, but he cannot tick or untick them.
## Related articles
- [Site roles](/docs/site-roles) for the full permission catalogue.
- [Hierarchies](/docs/hierarchies-in-cirrus-setting-up-groups-and-subdomains) for setting up the tree.
- [Manually add or manage a user](/docs/manual-administration-of-users)
- [Import users via Excel](/docs/importing-users)
