RackHelm keeps every person who can sign in — your own staff, your customers, their colleagues and one-off guest enquirers — in a single account list. What separates a member of staff from a customer is not a different table or a different login page, but the roles attached to the account. This article explains that model so the rest of the section makes sense.
One account list, two audiences #
Every account lives in the users table and signs in at the same /login form. Everyone — staff included — is sent to the client portal at /dashboard after signing in. What the roles on the account decide is what happens next:
- An account holding a role marked as a staff role can go on to the admin area at
/admin. - Every other account is a customer and stays in the client portal.
There is no separate “staff” record to create and keep in step with a customer record. Promoting a customer to staff is a matter of adding a staff role to their existing account, and demoting them is a matter of removing it.
What makes an account staff #
The Staff role switch is a property of the role, not of the user. RackHelm treats an account as staff when any role assigned to it carries that flag. Four of the five built-in roles do: Super Admin, Administrator, Billing Manager and Support Agent. The fifth, Client, does not.
Three checks run on every admin-area request, in this order:
- You must be signed in.
- You must be staff — otherwise RackHelm turns you away from
/adminentirely. - You must have confirmed your password recently, and if two-factor authentication is being enforced for your role you must have set it up.
Only after those pass does the individual permission on the screen you asked for get checked. So a staff account with no permissions at all can sign in to the admin area but will find almost every page returns a 403.
Note: Only a Super Admin can mark a role as a staff role. When anyone else creates or edits a role, the switch is either hidden or ignored on save.
The five kinds of account you will meet #
| Kind | How it is created | What it means |
|---|---|---|
| Staff | Created in Users & Roles → All Users → New User, then given a staff role | Can reach /admin. Cannot be made a sub-account of anyone. |
| Customer | Self-registration, or created by staff | Holds the default client role and owns orders, invoices, services and credit. |
| Guest | Created automatically when someone raises a support ticket without an account, or emails your support address | A placeholder so the ticket has an owner. Guests cannot sign in — the login form tells them “Guest accounts cannot log in. Please register a full account.” Following a password-reset link converts the guest into a full account. |
| Sub-account | Created by a customer, or by staff on the customer’s profile | A colleague’s login attached to a parent account. Billing, services and invoices all resolve to the parent. See Sub-Accounts. |
| Disabled | Set by the platform, not by a screen | Sign-in is refused with “This account has been disabled.” Applied to the placeholder rows the inbound-mail importer creates. |
How a new account gets its role #
When somebody registers on your public site, RackHelm attaches whichever role is flagged Default client. Exactly one role carries that flag at a time, and the seeded Client role is the one that carries it. No admin screen exposes a control for moving the flag — the roles list shows it as a badge only.
Accounts you create yourself in the admin area are different: they get whatever roles you tick on the create form, and nothing at all if you tick none. An account with no roles behaves as an ordinary customer, because permissions come only from roles.
Warning: The default client role is a permission grant. Whatever permissions it holds are handed to everyone who can self-register. RackHelm blocks the routes into that mistake: the client-default role neither inherits from other roles nor lends its permissions to them, new roles are always inserted immediately above it, and the flag cannot be moved from any admin screen. Keep the Client role’s effective permission count at zero and the grant stays empty.
The rules RackHelm enforces for you #
- Staff cannot be sub-accounts. If an account that is a sub-account gains a staff role, its link to the parent is cut the moment the account is saved.
- You can only manage accounts ranked below you. Roles sit in a ranked list; the account you are acting on must sit strictly below your own highest role. This applies to reading a profile tab as much as to changing a password. See Roles and Permissions.
- Super Admin accounts are off limits to everyone except another Super Admin, and they cannot be deleted at all.
- You cannot delete your own account from the admin area.
Troubleshooting #
| Symptom | Cause and fix |
|---|---|
A new staff member is refused at /admin with “Unauthorized access to the staff panel.” |
Their role is not marked as a staff role, or no role was assigned. Check Users & Roles → Roles & Permissions: the role should show the Staff or Built-in type badge. |
A staff member reaches /admin but every page returns 403. |
Their role carries the staff flag but no permissions. Open the role and grant what they need. |
| A permission change appears to have no effect. | Effective permissions are cached for 24 hours per account. Saving a role, reordering roles or changing a user’s roles clears the cache automatically; an edit made straight in the database does not. |
| A customer says they cannot log in and were told to register, but they already have an account. | Their row is a guest placeholder created from a ticket. Ask them to use Forgot password — completing the reset promotes the guest to a full account. |
| Opening a colleague’s profile returns “You can only manage accounts ranked below your own role.” | They hold a role at or above yours. Only someone ranked higher — usually a Super Admin — can open that profile. |
