Roles & Capabilities: The Permissions Model

In Aeon, you never grant permissions to a person directly. You define a role — a named bundle of permissions like Front Desk, Photoduplication, or Reading Room Supervisor — and then assign that role to staff members. Everyone holding the same role gets exactly the same access, and when you adjust the role, the change reaches every staff member on it at once.

A role answers three separate questions about a staff member:

1. What can they do in the day-to-day workspace? — process requests, edit users, send email, run batch processes, and so on. These are operational capabilities.
2. What parts of the Customization Manager can they configure? — designers, queues, billing defaults, staff accounts, roles themselves. These are configuration capabilities.
3. Which sensitive fields are they allowed to see? — government IDs, contact details, billing amounts. These are field restrictions.

Understanding these three layers is the key to setting up roles that fit your reading room. This page explains the model; the pages that follow walk through actually creating, editing, and assigning roles.

When this matters

You'll lean on this model whenever you:

• design a new role for a group of staff who should see and do less (or more) than the defaults,
• need to explain why a coworker can open a request but can't route it, or can't see a patron's date of birth, or
• want to give someone Customization Manager access for one area (say, email templates) without handing them the keys to everything.

The two starting roles

Every Aeon 7 site begins with two built-in roles. You can assign staff to them immediately, clone them as a starting point, or leave them alone — but you can't delete them.

Role	What it grants	Typical use
Administrator	Everything — every operational capability at Full, and every configuration area enabled. Its description reads "Full access to all features and configuration."	Site managers and customizers who run the whole system.
Staff	Full operational access (every operational capability at Full), but no configuration access at all. Its description reads "Full operational access, no system configuration."	Processing staff who do the daily work but shouldn't change how Aeon is configured.

Why "Staff" can do everything but configure nothing

The two seeded roles are deliberately identical on the operational side and opposite on the configuration side. That captures the most common split in a reading room: the people doing the work versus the people setting up the system. From there, you build narrower roles by cloning one of these and dialing capabilities down. See System Default Roles: Administrator and Staff for the full breakdown.

When you upgrade an existing site to Aeon 7, your current staff are mapped onto these two roles automatically: anyone who had Customization Manager access becomes an Administrator, and everyone else becomes Staff. You then refine from there.

Layer 1 — Operational capabilities

Operational capabilities control what a role can do in the main workspace. There are ten categories, and each one is set to one of four access levels.

The ten categories are:

Category	Covers
Requests	Opening, editing, routing, and processing requests
Users	Patron records — viewing, editing, clearing
Activities	Activity records and their members
Appointments	Reading room appointments
Reading Room	Sign-in/out, seating, away status
Email	Sending email and working with the outgoing queue
Batch Processing	Bulk workflow actions across many records
Billing	Charges, payments, invoices
Web Alerts	Patron-facing web alerts
Reports & Export	Running reports and exporting data

The four access levels

Each category is granted at exactly one level. The levels are cumulative — each includes everything below it:

Level	Meaning
None	No access. The role can't see this area at all.
View	Read-only. Can open and look, but can't change anything.
Edit	Can view and make changes (for requests, this is the level that lets you lock and edit a record).
Full	Everything Edit allows, plus the higher-impact actions in that category.

How access levels map to real actions

Because the levels are cumulative (None → View → Edit → Full), a role set to Edit for Requests automatically has everything View gives, and Full has everything Edit gives. A concrete example: opening a request to read it needs only the View level, but the moment you start editing — which acquires the record lock — you need the Edit level. See Opening & Locking a Request for that workflow in action.

For the exact actions each level unlocks per category, see the Permissions Matrix Reference.

In the role editor, you set these on the Operational tab, where each category is a row and the four levels (None, View, Edit, Full) are radio buttons across it. The tab is headed "Operational Capabilities — Control what this role can do in the main workspace."

Layer 2 — Configuration capabilities

Configuration capabilities control access to the Customization Manager — the admin side of Aeon where the system itself is set up. Unlike operational capabilities, these are simple on/off toggles: a role either has access to a configuration area or it doesn't. There's no View/Edit distinction.

There are ten configuration groups:

Group	Controls
Data & Fields	Custom fields, lookup tables, and field definitions
Designers	Card, form, and print template designers
Workflow	Queues, routing rules, and cancellation reasons
Web Interface	Flags, alerts, and web interface settings
Integrations	Addons, Z39.50, and external integrations
Operations	Sites, site groups, reading rooms, and system settings
Billing	Billing defaults, accounts, and service packages
Staff	Staff user management
Roles & Permissions	Role definitions, field groups, and staff role assignments
Implementation	Guided implementation wizard for new and existing sites

This is what lets you create a focused admin role — for example, someone who manages Workflow and Designers but has no access to Staff or Roles & Permissions.

You set these on the Configuration tab of the role editor.

Roles & Permissions is the master key — and it's self-protecting

The Roles & Permissions group is the one that lets a role open this very area and edit roles. Aeon guards it so an admin can't accidentally lock everyone out:

• You can't strip your own admin access. If you try to turn off Roles & Permissions for the role you yourself hold, Aeon refuses with "Cannot remove Roles & Permissions access from your own role. This would lock you out of the admin UI."
• You can't remove the last admin. If a role is the only one with Roles & Permissions access (and staff assigned to it), Aeon blocks the change — "Cannot remove Roles & Permissions access from this role. It is the only role with admin access. Grant another role Roles & Permissions access first."

The same protection applies when deleting a role. See Protecting Against Lockout: One-Admin Minimum for the full set of guard messages.

Layer 3 — Field restrictions

The first two layers decide which screens and actions a role can reach. Field restrictions go one level deeper: they hide specific fields even on records the role is otherwise allowed to open.

This is done with field groups — named bundles of sensitive columns. Aeon includes three system-default groups:

Field group	Hides	Example fields
Personal Identifiers	Government IDs and date of birth	ID, ID Type, Alternate ID, Date of Birth
Contact Information	Phone numbers, fax, and physical addresses	Phone, Fax, Address, City, State, Zip, Country
Financial	Billing amounts, payment details, and invoice information	Maximum cost, invoice number, base/unit fees, payment method, payment amount, authorization code

When you assign a field group to a role as a restriction, members of that role can still open the user or request, but the listed fields are hidden from them. You manage this on the Field Restrictions tab of the role editor.

Restrictions hide, they don't grant

A field restriction only ever takes away visibility. A role with no restrictions sees every field its operational level allows. This is how you let, say, a student worker process requests while keeping patron dates of birth and credit-card details out of view. You can also build your own groups beyond the three defaults — see Field Restriction Groups.

How the three layers fit together

For any given staff member, Aeon resolves access by stacking the layers:

Role → Operational capabilities (what you can do)
     + Configuration capabilities (what you can configure)
     − Field restrictions          (what you can't see)

A worked example. Suppose you create a Front Desk role:

• Operational: Users at Full, Appointments at Full, Reading Room at Full, Requests at View, everything else None.
• Configuration: all groups off.
• Field restrictions: the Financial group.

A staff member with this role can clear patrons, book appointments, and sign people into the reading room, and can look at request #12345 without being able to edit or route it. They have no Customization Manager access at all, and billing amounts are hidden from them everywhere. That single role, applied to your whole front-desk team, keeps their access consistent.

The role editor at a glance

When you open a role, the editor is organized into tabs that line up with this model:

Tab	What you set
General	Role name and description, plus a read-only summary of the role's capabilities
Operational	The ten operational categories and their access levels (Layer 1)
Configuration	The ten configuration-group toggles (Layer 2)
Field Restrictions	Which field groups this role can't see (Layer 3)
Layouts	Custom form, card, and queue layouts shown to this role
Members	The staff members currently assigned to this role

A built-in role (Administrator or Staff) shows a small lock icon next to its name and can't be deleted, though you can still assign and reassign staff to it.

Saving a role signs affected staff back in

When you save a change to a role, every staff member on that role has their active session invalidated — they'll be prompted to sign in again, and the new permissions take effect once they do (not mid-session). Plan role changes accordingly for a busy desk.

Where to go next

• Permissions Overview — the dashboard view of roles, staff, and field groups
• Creating a Custom Role and Cloning a Role — building your own roles
• Editing a Role: Operational Capabilities / Configuration Capabilities / Field Restrictions
• Assigning Roles to Staff
• Permissions Matrix Reference — the complete table of every category, group, and level