Editing a Role: Operational Capabilities
A role's operational capabilities decide what the people in that role can do in the everyday workspace — open and edit requests, work with users, send email, run batch processes, touch billing, and so on. This is the most common thing you'll adjust on a role: it's how you make a "Front Desk" role that can sign users in but can't edit billing, or a "Student Worker" role that can read requests but not route them.
Each of the ten operational areas gets one of four access levels. Most roles never need every area turned all the way up — you grant each area only as far as that role's work requires, and leave the rest at None. The two built-in roles already sit at the extremes: Administrator and Staff both come with every operational area set to Full; the difference between them is configuration access, not operational access. You'd create a custom role precisely to land somewhere in between.
- You're building a custom role (front desk, reading-room attendant, student worker) and need to dial in exactly which workspace actions it allows.
- A role can see more — or less — than it should, and you want to raise or lower one area without touching the rest.
- You cloned a role as a starting point and now need to trim its access down to fit a narrower job.
Where this lives
Operational capabilities are edited on the Operational tab of the role editor, inside the Roles & Permissions section of the Customization Manager.
- Open the Customization Manager and go to Roles & Permissions → Roles.
- In the left-hand list, click a role — for example, Front Desk — to open it.
- In the role editor, select the Operational tab.
You'll see a table with one row per operational area and four columns of radio buttons: None, View, Edit, Full.
The same role editor also has tabs for General (name and description), Configuration (what the role can configure in the Customization Manager), Field Restrictions, Layouts, and Members. This page covers only the Operational tab. The Save and Discard buttons at the top of the editor apply to the whole role, so a change you make here is saved alongside any pending changes on the other tabs.
The four access levels
Every operational area is set to exactly one level. The levels are cumulative — each one includes everything below it:
| Level | What it grants |
|---|---|
| None | No access to this area at all. The role can't see or use it. |
| View | Read-only. The role can open and look at records in this area but can't change them. |
| Edit | Create and change records — the normal "do the work" level. Includes everything View allows. |
| Full | Edit plus the higher-privilege and destructive actions in that area (for example, cancelling or deleting). Includes everything Edit allows. |
Each level maps to what the underlying actions require. For requests, for instance, viewing a request needs View; editing it and running the everyday workflow actions (Check Out, Place On Hold, and the like) need Edit — this is also where the record lock turns on; and the higher-impact actions — using the Route menu, cancelling, merging — need Full. The pattern is the same across areas: read at View, do the work at Edit, and the irreversible or sensitive operations at Full. When in doubt, Edit is the level that lets a role actually process work; reserve Full for staff you trust with deletions and cancellations.
The ten operational areas
These are the rows you'll set, with the exact labels as they appear in the table:
| Area | Covers |
|---|---|
| Requests | Opening, editing, routing, cloning, cancelling, and otherwise processing requests. |
| Users | Viewing and editing user records, clearance, notes, and related actions. |
| Activities | Activities and their members, attendance, and requests. |
| Appointments | Appointment calendars, scheduling, confirming, and cancelling. |
| Reading Room | Reading-room sign-in/out, seating, and away status. |
| Composing and sending email, and the outgoing-email queue. | |
| Batch Processing | Running standard and custom batch processes on selected requests. |
| Billing | Charges, payments, invoices, and billing accounts on requests and users. |
| Web Alerts | Web-interface alerts shown to patrons. |
| Reports & Export | Running reports and exporting data. |
Setting a level
- Open the role and go to the Operational tab — for example, the Front Desk role.
- Find the area you want to change, such as Reading Room.
- Click the radio button in the column for the level you want — say, Edit — so the reading-room attendant can sign users in and out but not delete records.
- Repeat for any other areas. A typical front-desk role might be Users: Edit, Reading Room: Edit, Appointments: Edit, and everything else left at None or View.
- At the top of the editor, click Save.
When the save succeeds you'll see a confirmation — Role "Front Desk" saved. If you change your mind before saving, click Discard to revert every pending change on the role back to its last-saved state.
The Save and Discard buttons stay disabled until you've actually changed something, and they act on all tabs at once. You can adjust operational levels, switch to the Configuration tab, make a change there too, and then save both with a single click.
What happens to staff already in the role
Changing a role's operational levels takes effect for everyone assigned to that role — not just the next person to sign in.
When you save changes to a role, Aeon refreshes the permissions of every staff member currently assigned to it. Their existing sign-in is invalidated and re-issued with the new access levels, so a capability you remove stops working right away, and one you add becomes available without anyone needing to sign out and back in. Keep this in mind before lowering a level mid-shift: anyone in that role loses the removed access on their next action.
Built-in roles and a few cautions
The two system default roles, Administrator and Staff, are marked with a lock icon in the role list, but their operational levels can still be edited. They both come with every area at Full. Lowering an operational level on Staff affects everyone using that default role, so prefer creating a custom role for narrower access rather than weakening Staff.
Note that the operational tab does not govern who can manage roles. The ability to open this editor at all is a configuration capability — Roles & Permissions — set on the Configuration tab. That's also where Aeon's lockout protections live (it won't let you remove your own admin access, or strip the last admin role). Setting operational levels here can't lock you out of the admin UI.
If a new role is close to an existing one, clone the existing role first (right-click it in the list, or use Clone Role from the editor menu) and then trim the operational levels down. It's faster and less error-prone than starting every area at None and building up.