Admin roles and account security
Overview
Two questions, and most organizations only think about the first: who gets in, and what can they reach once they are in.
This article covers admin roles, how site links and roles relate, the Account Holder, and two-factor authentication. It is for administrators setting up a team.
1. What is the Account Holder?
One person, and the role is deliberately special.
The Account Holder cannot be deleted and cannot be assigned to a different role. They are the only person who can reach the subscription, and the only one who can change another administrator's permissions. Some organization-wide settings are set by them and apply to every administrator in the portal.
This matters for a practical reason: if the Account Holder is somebody who has left, or a shared address nobody monitors, you have a problem before anything goes wrong. Transfer it deliberately with Make account holder rather than discovering the gap during an emergency.
2. If I use Sites, do I need admin roles at all?
Usually not. This is the most useful thing on this page and the most commonly missed.
Linking an administrator to a site is already a scope limit. It confines them to that site's people and work on its own, with no admin role involved. For a lot of multi-location organizations that is the whole permissions setup, finished.
Admin roles are then the exception layer, for the two cases site links cannot express:
- Narrowing further inside a site. Somebody linked to a site who should still not reach everything within it.
- Reaching outside their site. Somebody linked to one site who needs specific access beyond it, such as a regional coordinator who owns one site but reports across three.
So the order is: link to a site first, and add a role only when you hit one of those two cases. Building elaborate roles alongside site links usually means two systems doing one job, and it becomes very hard to answer "why can this person see that".
3. What if we do not use Sites?
Then admin roles do the whole job, and they do more than scope.
A role controls both:
- Which modules an administrator can reach at all
- What they can do there, meaning create, edit and delete as separate capabilities
That second part is worth using. Somebody who needs to read the schedule and mark attendance does not need permission to delete shifts, and the difference between view and delete is the difference between a mistake and an incident.
4. How else can I limit which profiles an administrator sees?
Beyond the site link, profile access can be limited to:
- Only profiles assigned to opportunities they have access to
- Only profiles carrying specific profile tags
- Both conditions at once
5. Careful: Both means AND, not OR
Choosing both conditions means a profile has to satisfy the two of them together to be visible, not either one.
It is the tightest setting available and it is easy to pick by accident, because it reads like it should widen access rather than narrow it. The symptom is a coordinator who signs in and sees almost nobody. If that happens, this is the first thing to check.
6. Does scoping apply everywhere automatically?
No, and this is the part that catches people out.
The same scoping is set separately for what an administrator can reach in:
- Profiles in the database
- Form submissions
- Sequences
- Chat
Setting one does not set the others. An administrator correctly limited to their own programme's profiles can still be able to read every form submission in the organization if you never scoped that separately. Check all four rather than assuming they follow the profile setting.
7. What is two-factor authentication?
A code at login on top of the password. The administrator registers a secure phone number and enters a code each time they sign in.
You decide whether it is offered or required, and whether that applies to administrators, to end users, or to both.
8. Who should I require it for?
If you do only one thing on this page, require it for administrators.
- Required for administrators. The accounts with the most access are protected, and you are not asking your whole database to set up a second factor. This is the right answer for most organizations.
- Required for everyone. Strongest, and justified where profiles hold sensitive information. Expect a run of support requests from people who have changed phones.
- Offered, not required. Available to anyone who wants it. In practice very few people enable it themselves, so if it matters, require it.
The reasoning is simple: an administrator account can export your entire database. A user account cannot.
9. What happens if somebody changes their phone?
Their 2FA is tied to the verified number. Removing that number disables 2FA for them until they verify a new one.
Worth knowing before you enforce it for everyone, because phone changes are the single most common support request that follows.
10. Is this the same as single sign-on?
No. Two-factor authentication is available on every plan. Single sign-on needs Ultimate, is configured separately, and can be enforced so that it becomes the only way in.
If SSO is out of reach, 2FA is the security control to turn on instead. It is not a lesser version of the same thing, and plenty of organizations run both.
Summary
- The Account Holder is unique, cannot be deleted or reassigned, and owns the subscription and permissions. Transfer it deliberately.
- If you use Sites, linking an administrator to a site is usually enough on its own. No role required.
- Add an admin role only to narrow further inside a site, or to grant access beyond it.
- Without Sites, roles do the whole job: which modules, plus create, edit and delete as separate capabilities.
- Profile access can also be limited by opportunity, by profile tag, or by both.
- Both means AND. The narrowest setting, and the usual cause of an admin seeing almost nobody.
- Scoping is set separately for profiles, form submissions, sequences and chat. Check all four.
- Two-factor authentication is on every plan. Require it for administrators at minimum.
- Single sign-on is Ultimate and separate from 2FA.