Permissions Matrix Reference

Most of the time you don't read this page — you build a role on the Roles page, pick levels from the on-screen controls, and Aeon enforces them. This is the reference you reach for when you're designing a role and need to know exactly what each switch controls: what "Edit" gives someone that "View" doesn't, which part of the Customization Manager a configuration group unlocks, or which fields a default field group hides.

Everything a role can grant lives in three layers. The first two are what you set on a role; the third is a separate restriction layer. The tables below are the authoritative list of every value in each layer. One operational grant, Atlas BI, sits on the same tab as the rest but carries its own levels — it has its own table below.

When you'll use this

• You're creating or editing a role and want to confirm what a given level actually permits before you save it.
• A staff member can (or can't) do something and you're tracing which capability and level is responsible.
• You're planning a least-privilege role and need the full menu of categories and groups to choose from.

The three layers at a glance

Layer	What it controls	How you set it	Where you see it
Operational capabilities	What the role can do in the main workspace (requests, users, billing, …)	A level per category: None / View / Edit / Full — except Atlas BI, which uses No access / Viewer / Contributor	Role editor → Operational tab
Configuration capabilities	Which sections of the Customization Manager the role can open	An on/off toggle per group	Role editor → Configuration tab
Field restrictions	Which sensitive fields are hidden from the role	Field groups assigned to the role	Role editor → Field Restrictions tab

Access levels

The ten workspace categories use four levels. They are cumulative and ordered — each level includes everything the levels below it allow, so granting Full also grants View and Edit, and granting Edit also grants View. (Atlas BI is the exception: three levels of its own, described in Atlas BI access.)

Level	Meaning
None	No access. The feature is hidden or disabled for the role.
View	Read-only. The role can open and read records in the category but cannot change them.
Edit	View, plus the ability to create and modify records — including locking a record for editing.
Full	Edit, plus the higher-impact actions in the category (for example, deleting, or other privileged operations).

How the level is checked

Aeon compares the role's level against the level a feature requires, using the order None < View < Edit < Full. A feature that requires Edit is available to anyone at Edit or Full; a feature that requires View is available at View, Edit, or Full. This is why you only ever pick one level per category — the higher levels automatically cover the lower ones. A category can cap how high it goes: Atlas BI stops at Edit, so Full cannot be set on it from any client.

Operational capabilities

These ten categories appear as rows on the role editor's Operational tab, each with a None / View / Edit / Full selector. The tab is introduced on screen as "Control what this role can do in the main workspace." The Atlas BI section below the grid is part of the same tab and is covered in Atlas BI access.

Category (on-screen label)	Governs
Requests	Opening, editing, routing, cloning, merging, cancelling, and otherwise processing requests. Edit is the level required to lock a request for editing.
Users	Viewing and editing patron (user) records, clearance, notes, proxies, and related user actions.
Activities	Viewing and editing activities, their members, attendance, and activity requests.
Appointments	Viewing, creating, editing, confirming, and cancelling reading-room appointments.
Reading Room	Signing patrons in and out, marking them away, and assigning seating and locations.
Email	Composing and sending email, and working with the outgoing email queue (pending and failed).
Batch Processing	Running batch / bulk workflow processes across multiple requests.
Billing	Viewing and editing charges, payments, invoices, and billing accounts on requests and users.
Web Alerts	Viewing, creating, editing, and deleting web alerts.
Reports & Export	Exporting data — for example, exporting the results of a bulk selection or a custom search. (The category is labeled Reports & Export, but in the current release it controls the export actions.)

note

Categories gate operations, not field-level visibility

A category level controls whether a role can perform an action — for example, whether someone can edit a user record at all. It does not, on its own, hide individual fields within a record the role can see. Hiding specific sensitive fields is the job of field restrictions (below).

Atlas BI access

Atlas BI is an external reporting system, so its grant sits in its own section below the grid on the Operational tab rather than as an eleventh row. It has three levels of its own, and no role has any access until you choose one.

Level (on-screen label)	Grants
No access	Cannot open Atlas BI. Both built-in roles are here, and an upgrade never moves a role off it.
Viewer	Can open Atlas BI and view dashboards and reports, but cannot change anything.
Contributor	Can view, create, and modify dashboards and reports in Atlas BI.

Contributor is the ceiling. There is no Full level for Atlas BI: the API refuses one, and a database constraint refuses it too, so a value written outside Aeon can't grant more than Contributor either.

The staff member also needs an address configured

Open Atlas BI, under Reporting in the ⋯ menu, appears only when the role grants Viewer or Contributor and an administrator has set a usable address in the AtlasBIURL customization key. The capability alone doesn't reveal it.

Configuration capabilities

These eleven groups appear as checkboxes on the role editor's Configuration tab, introduced on screen as "Control which sections of the Customization Manager this role can access." Each is a simple on/off toggle — there are no View/Edit/Full levels for configuration. A role with a group off does not see that part of the Customization Manager at all.

The label and one-line description below are exactly what appears beside each checkbox.

Group (on-screen label)	On-screen description
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
System Diagnostics	Application logs and troubleshooting diagnostics

Roles & Permissions is the one that can lock you out

The Roles & Permissions group is what lets a role open this very area — roles, field groups, and staff role assignments. Removing it from your own role is the one change that can shut you out of permissions management entirely. If you try, the editor warns you on the spot: "You are removing Roles & Permissions access from your own role. If saved, you will be locked out of this settings page." Aeon also refuses to leave the system with no administrator at all. See Protecting Against Lockout: One-Admin Minimum for the full rules.

Field restrictions

Field restrictions are the third layer. Instead of controlling actions, they hide specific fields from a role even on records the role is otherwise allowed to open. You apply them by assigning one or more field groups to a role on the Field Restrictions tab. A field group is just a named bundle of columns (for example, a patron's government ID fields). Assign the group to a role, and those fields are hidden for everyone in that role.

Aeon includes four system-default field groups. These can't be deleted, but you can edit them, assign them to any role, and create your own custom groups alongside them.

System-default field group	What it hides
Personal Identifiers	Government IDs and date of birth (the user's ID, alternate ID, their types, and date of birth).
Contact Information	Phone numbers, fax, and physical addresses (mailing and shipping address fields).
Financial	Billing amounts, payment details, and invoice information (max cost, account/invoice numbers, base/unit fees and tax rate, and payment method, reference, amount, and authorization code).
Atlas Support Privacy	Patron data hidden from Atlas Systems support sessions by default — last name, email address, phone, fax, both the mailing and shipping address blocks, ID and Alternate ID with their types, and date of birth (21 fields).

Atlas Support Privacy is assigned differently from the other three

The other three do nothing until you assign them to a role. Atlas Support Privacy is the group Support Access selects by default, and its restrictions then apply to every support session on top of whatever role the session was granted. Pointing Support Access at no group at all is a deliberate loosening. You can still edit which fields the group holds, and assign it to a role like any other — but a support session can never edit the group or change which group is selected.

Field restrictions only reach restrictable data

Field groups can only target fields Aeon has marked as restrictable. Six tables carry restrictable fields — Users, Transactions, Activities, Appointments, BillingDetail, and BillingPayment — so a field group can reach request fields as well as patron and billing data. A handful of identity fields are held back because they're what ties a record to its owner: a user's username, a request's transaction number, and an activity's ID. For the full list and how to build and assign your own groups, see Field Restriction Groups and Creating a Custom Field Restriction Group.

The two built-in roles

Every Aeon site starts with two system-default roles. They mark the two ends of the spectrum and can't be deleted, which makes them a useful reference point when you're deciding what a custom role should grant.

Role	Operational capabilities	Atlas BI	Configuration capabilities	Field restrictions
Administrator	All ten categories at Full	No access	Every group on	None
Staff	All ten categories at Full	No access	Every group off	None

In other words, the only difference between the two built-in roles is configuration access: Staff can do everything in the day-to-day workspace but can't open the Customization Manager, while Administrator adds full configuration access on top. A custom role is simply a different mix — lower some operational levels, turn on only the configuration groups a person needs, and add field restrictions where data should be hidden. See System Default Roles: Administrator and Staff for more on when to use each.