---
title: "The Five Built-in Roles"
description: "RackHelm seeds five roles when it is installed. Four of them are staff roles; the fifth is the role every self-registering customer receives. This article says exactly what each one can do out of the box, so you can pick…"
url: "https://rackhelm.com/documentation/built-in-roles/"
updated: "2026-09-24"
category: "Clients, Staff & Access Control"
---

# The Five Built-in Roles

RackHelm seeds five roles when it is installed. Four of them are staff roles; the fifth is the role every self-registering customer receives. This article says exactly what each one can do out of the box, so you can pick the closest fit rather than building a role from 88 switches.

## The five roles at a glance

| Rank | Role | Staff | Effective permissions | In one line |
| --- | --- | --- | --- | --- |
| 1 | **Super Admin** | Yes | 88 of 88, plus a blanket override | The owner account. Nothing is withheld. |
| 2 | **Administrator** | Yes | 78 of 88 | Day-to-day running of the business, minus ten sensitive keys. |
| 3 | **Billing Manager** | Yes | 38 of 88 | Money: orders, invoices, credit, coupons, revenue reports — and, by inheritance, tickets. |
| 4 | **Support Agent** | Yes | 15 of 88 | The ticket queue, with read-only sight of clients, orders, invoices and products. |
| 5 | **Client** | No | 0 | The default role for customers. Holds no staff permissions at all. |

> **Note:** "Effective" includes inheritance. A role holds its own permissions plus everything held by the roles ranked below it, except the client default, which is excluded from inheritance in both directions. This is why Billing Manager's effective total is larger than the list its own switches show.

## Super Admin

Super Admin is not a large permission set so much as a bypass: any check made against a Super Admin account returns true before the permission list is even consulted. The installer creates one Super Admin account and prints its generated password once, at the end of installation.

Three protections exist around it:

- A Super Admin account cannot be deleted, and cannot be managed, impersonated or edited by anyone who is not also a Super Admin.
- Only a Super Admin can edit the Super Admin role, or grant it to somebody.
- Only a Super Admin can mark a role as a staff role.

Three permissions are held by Super Admin alone in a default installation, and each is withheld from Administrator for a specific reason rather than out of caution:

| Permission | Why it stays with Super Admin |
| --- | --- |
| `login_as_client` | Impersonation gives whoever holds it the customer's own session: their services, stored payment methods and control-panel links. It is a support tool, not a routine one, so it is handed out per installation rather than by default. |
| `manage_notifications` (with `view_notification_logs`) | A notification destination is an outbound copy of portal activity. Anyone who can create one can point every order, payment and ticket event at a server they control — a broader leak than impersonation, which is already withheld. |
| `manage_custom_apis` | A Custom API integration is an operator-defined outbound HTTP call where the holder picks both the destination URL and the payload template. That is a pipe for client data and service credentials, pointed wherever its author chooses. |

> **Tip:** If your support team genuinely needs impersonation, grant `login_as_client` to a role you control rather than making people Super Admins. The same goes for the other two.

## Administrator

Administrator is defined the other way round from the rest: it receives *every* permission except a named list of ten. The practical effect is that a new permission added in a future release lands on Administrator automatically.

The ten withheld keys are:

| Withheld | Consequence |
| --- | --- |
| `edit_roles`, `delete_roles` | An Administrator can see the role hierarchy but cannot rewrite it — the boundary that keeps them below Super Admin. |
| `view_settings`, `edit_company_settings` | Company details, branding, mail, gateways, CAPTCHA, fraud, MFA and password policy stay with the owner. |
| `manage_email_routes` | Inbound mail routing decides where support email lands. |
| `manage_schedules` | Invoice generation, renewals and suspensions run on these schedules. |
| `login_as_client` | No impersonation. |
| `manage_notifications`, `view_notification_logs` | No outbound notification destinations, and no reading of what was sent. |
| `manage_custom_apis` | No operator-defined outbound API calls. |

Everything else — clients, orders, invoices, the catalogue, tickets, integrations, pages, navigation, reports and audit logs — is available to an Administrator.

## Billing Manager

Twenty-seven permissions are ticked directly on this role:

- **Clients:** `view_clients`, `edit_clients`, `view_credit_balances`, `add_client_credit`, `remove_client_credit`, `view_transactions`.
- **Orders:** `view_orders`, `edit_orders`, `provision_orders` — note there is no `create_orders`, so a Billing Manager cannot place an order and charge a card.
- **Invoices:** `view_invoices`, `create_invoices`, `edit_invoices`, `refund_invoices`, `mark_invoices_paid` — but not `delete_invoices`.
- **Catalogue:** `manage_coupons`.
- **Reporting:** `view_dashboard`, `view_reports`, the seven revenue and customer reports, and the income, invoice and provisioning dashboard widgets.

> **Warning:** Because Billing Manager ranks directly above Support Agent, it also inherits all fifteen of that role's permissions — including `reply_tickets`, `close_tickets`, `assign_tickets` and `manage_canned_replies`. If you want a billing role with no access to the ticket queue, move it *below* Support Agent in the hierarchy, or build a custom role in a position that inherits nothing you object to.

## Support Agent

Fifteen permissions, aimed squarely at the helpdesk: `view_dashboard`, `view_tickets`, `create_tickets`, `reply_tickets`, `assign_tickets`, `close_tickets`, `manage_canned_replies`, `view_departments`, read-only `view_clients`, `view_orders`, `view_invoices` and `view_products`, plus the two ticket reports and the ticket dashboard widget.

An agent can therefore look up a customer's services and invoices while answering them, but cannot change anything: no editing clients, no credit adjustments, no refunds, no order changes. Ticket visibility is narrowed further by department membership.

Note what is *not* there: `delete_tickets` and `view_client_activity`. An agent cannot destroy a ticket thread or read a customer's sign-in history.

## Client

The Client role carries no permissions and is flagged as the default for clients, which means the registration form attaches it to every new account. Its permission count is deliberately zero, and it neither inherits from other roles nor lends anything to them. Customer capability in the portal comes from ownership of the account's data, not from this role.

## Customising the built-in roles

> **Warning:** The five built-in roles are re-synchronised every time the database seeders run, including during the installer's `php artisan migrate --seed --force`. Any permission you add to or remove from them by hand is discarded at that point. Roles you create yourself are never touched, so express local policy as a custom role.

A practical pattern: leave Administrator, Billing Manager and Support Agent as they are, create **Senior Support** or **Accounts** as custom roles, and position them carefully in the hierarchy — remembering that a role inherits everything beneath it.

## Troubleshooting

| Symptom | Cause and fix |
| --- | --- |
| A Billing Manager is replying to tickets. | Inheritance from Support Agent, which sits below them. Reorder the roles or move the person to a custom role. |
| An Administrator cannot open Company Settings. | Working as designed — `edit_company_settings` is withheld from Administrator. Grant it explicitly if that suits your team. |
| An Administrator has no Impersonate button. | `login_as_client` is withheld by default. Grant it from **Roles & Permissions**. |
| The role counts on the list do not match the switches you ticked. | The list shows effective permissions including inheritance. Open the role: inherited entries are the greyed, padlocked ones. |
| You changed a built-in role and the change vanished. | The seeders ran. Rebuild the change as a custom role. |
| Every customer suddenly holds staff permissions. | Permissions were ticked onto the Client role itself — it is the only way it can hold any, since it inherits nothing. Open it and clear them; its effective count should read 0. |