Adding Staff Members

A member of staff is an ordinary RackHelm account that happens to hold a role marked as a staff role. There is no separate staff screen: you create the account on the same form you use for customers, then give it the right role. This article covers the whole sequence, including the two settings you should get right before your first staff member signs in.

Before you start #

Note: Creating the account needs create_clients, but assigning the staff role is guarded separately and in a default installation only a Super Admin can do it. Plan to have a Super Admin available for step 3.

Adding a staff member #

1. Decide which role they get. Use one of the built-in roles — Administrator, Billing Manager or Support Agent — or create your own first. See The Five Built-in Roles and Roles and Permissions.
2. Create the account. Open Users & Roles → All Users → New User and enter their email, a temporary password twice, and their name.
3. Assign the role. Pick it in Assigned Roles on the same form, or afterwards on the account’s Contact tab. The moment a staff role is attached, the account can reach /admin.
4. Add them to departments if they will answer tickets. Under Support → Departments, add them individually in the Staff members card. Direct department membership — or a ticket assigned to them by name — is what decides which tickets they can see, including on the Tickets tab of a customer’s profile.
5. Hand over the password out of band and ask them to change it, and to set up two-factor authentication, from their own account settings. RackHelm sends no email when you create an account this way.

Warning: A department also accepts a whole role under Assigned roles, and that card says “Everyone with these roles handles this department automatically” — but it does not grant ticket visibility. The queue filter reads direct staff membership and direct assignment only. Attaching the role lists the team on the department screen and nothing more, so always add each person under Staff members as well.

What a staff account experiences #

• They sign in at the same /login as everyone else and land on the customer dashboard at /dashboard, not in the admin area. The Admin Panel link in the portal sidebar is gated on a capability that is never granted, so only a Super Admin sees it — tell everyone else to go to /admin directly and bookmark it.
• The whole admin area sits behind a password confirmation: entering it prompts for their password again, and the confirmation then lasts three hours by default (AUTH_PASSWORD_TIMEOUT in .env, in seconds). This limits what an unattended, still-signed-in browser can do.
• Every screen is still permission-checked. A staff account with a role that carries no permissions can sign in and see almost nothing.
• Email verification is enforced on the client portal, not on /admin. An unverified staff account is stopped at the “verify your email” notice on /dashboard but can still work in the admin area.

Requiring two-factor authentication for staff #

Go to Security → MFA in the admin sidebar (/admin/settings/mfa). The whole Security group is checked against a capability name that is never granted to anyone, so in practice only a Super Admin can open it. Force Two-Factor Authentication offers three modes:

Show Recommendation Banner on the same screen puts a non-blocking prompt at the top of the portal for anyone who has not yet enrolled.

Tip: Enrol your own Super Admin account before switching the mode to Force for All Users, so you are not the one locked into the enrolment screen while trying to fix something else.

Removing staff access #

Remove the staff role from the account on the Contact tab and save. The change takes effect on their next request — cached permissions are cleared on save. The account survives as an ordinary customer account with its history intact, which is normally what you want for someone who has left.

Note that RackHelm will not let you delete a staff account from the users list at all: the Delete action is hidden for any account holding a staff role. Strip the role first if the account genuinely has to go.

Warning: Never reuse a live customer’s account as a staff login — create a separate one. Giving a customer account a staff role silently cuts its link to any parent account, and from then on that person’s own colleagues are logging in against an account that also holds admin access.

Permissions that look like staff controls but are not #

The permission list contains a Staff & Roles group with view_staff, create_staff, edit_staff and delete_staff. No screen currently checks those four keys — staff accounts are created, edited and deleted through the same create_clients, edit_clients and delete_clients permissions as customers, with the role hierarchy providing the real boundary. Granting the *_staff keys changes nothing; withholding them protects nothing.

The four *_roles keys in the same group are live and do gate the Roles and Permissions screens.

Troubleshooting #