System Default Roles: Administrator and Staff
Every Aeon system starts with two built-in roles you don't have to create: Administrator and Staff. They're the foundation of the permissions model — most sites assign people to one of these two and never build anything else. You only reach for a custom role when you need something in between, like a front-desk account that can process requests but shouldn't touch Customization Manager.
Both roles are marked as system default, which means Aeon protects them: you can rename them, adjust their capabilities, and clone them, but you cannot delete them. That guarantee is what keeps a site from accidentally removing the role its administrators depend on.
- You're setting up staff for the first time and need to know which role to assign — start here.
- You're deciding whether a person needs a custom role or whether Administrator or Staff already covers them.
- You tried to delete a role and Aeon stopped you — if it's one of these two, that's by design.
Where you'll see them
Both roles appear in Customization Manager → Roles & Permissions, on the Roles tab and in the role cards on the Overview tab. A system default role is shown with a small lock icon next to its name (there's no separate text label). That lock is the visual cue that the role is built in and can't be removed.
When you open a system default role, the editor works the same as any other role — you get the General, Operational, Configuration, Field Restrictions, Layouts, and Members tabs. The one difference: the Delete Role option is hidden from the role's actions menu (reached through the ⋯ button). Clone Role is still available there.
What each role grants
Aeon's permissions are built from three layers — operational capabilities (what you can do in the workspace, set per area to None / View / Edit / Full), configuration capabilities (which Customization Manager groups you can open, each a simple on/off), and field restrictions (whether specific sensitive fields are hidden from you). The two default roles differ only in the configuration layer.
Administrator
Full access to everything.
- Operational capabilities: every area — Requests, Users, Activities, Appointments, Reading Room, Email, Batch Processing, Billing, Web Alerts, and Reports & Export — set to Full.
- Configuration capabilities: every Customization Manager group enabled — Data & Fields, Designers, Workflow, Web Interface, Integrations, Operations, Billing, Staff, Roles & Permissions, and Implementation.
- Field restrictions: none. Administrators see all fields.
Its built-in description reads "Full access to all features and configuration."
Because Administrator holds the Roles & Permissions configuration capability, it's the role that can create roles, assign staff, and edit permissions. Aeon enforces that at least one role with this capability always has a staff member assigned — see Protecting Against Lockout: One-Admin Minimum. Keep at least one person on the Administrator role (or another role you've granted Roles & Permissions to).
Staff
Full operational access, but no configuration access.
- Operational capabilities: every area set to Full — same as Administrator. A Staff-role user can process requests, manage users, handle billing, send email, run batch processes, and everything else in day-to-day work.
- Configuration capabilities: every group disabled. Staff-role users cannot open any Customization Manager group, including Roles & Permissions.
- Field restrictions: none by default.
Its built-in description reads "Full operational access, no system configuration."
This is the right role for most day-to-day staff: they can do all the front-line work without being able to change how the system is configured.
The split between the two built-in roles is deliberately about configuration, not daily work. Out of the box, both Administrator and Staff can do everything in the workspace at the Full level; the only thing that separates them is whether they can reach Customization Manager. If you need someone who's limited in their day-to-day work too — for example, view-only on Billing, or no access to Reading Room — that's a job for a custom role, not one of these two. See Creating a Custom Role.
How existing staff get assigned during an upgrade
When you upgrade an Aeon 6 database to Aeon 7, your existing staff accounts are mapped onto these two roles automatically based on their legacy permissions:
- Staff who had Customization Manager access in the desktop client are assigned to Administrator.
- Everyone else is assigned to Staff.
So after an upgrade, the people who used to run the Customization Manager keep that power, and everyone else lands on the operationally-full-but-config-locked Staff role. You can refine any of these assignments afterward from the Staff tab.
On a brand-new (non-upgraded) multi-site install, the two roles exist but staff are not auto-assigned to them, and no site access is wired up — this is secure-by-default. An administrator has to grant the initial access before other accounts can sign in to the web client. If you're standing up a fresh system and can't log in, this is usually why; see your installation steps for granting the first administrator access.
Can I change or remove them?
| Action | Administrator | Staff |
|---|---|---|
| Rename | Yes | Yes |
| Edit capabilities | Yes | Yes |
| Edit field restrictions / layout assignments | Yes | Yes |
| Clone | Yes | Yes |
| Delete | No | No |
Trying to delete a system default role through the API returns the error "System default roles cannot be deleted." In the UI you won't even see a Delete option for them — it's removed from the actions menu.
You can edit them — for instance, you could tighten the Staff role's operational levels for your site. Just remember the guardrail: you can't strip Roles & Permissions access from the only admin role that has staff assigned, and you can't remove it from your own role. Those protections apply to every role, default or custom. See Protecting Against Lockout: One-Admin Minimum.
If you need a variant of one of the built-in roles, clone it rather than editing the original. Cloning copies all capabilities, field restrictions, and layout assignments into a new, fully-editable (and deletable) role, leaving the defaults intact as a clean baseline. See Cloning a Role.
Related pages
- Roles & Capabilities: The Permissions Model — how the three layers fit together.
- Creating a Custom Role — when the two defaults aren't enough.
- Permissions Matrix Reference — the full list of operational categories, configuration groups, and access levels.
- Managing Staff Accounts — assigning people to roles.