User Permissions and Role-Based Access
Most of the time you never think about permissions: you log in, the things you're meant to use are there, and the things you aren't don't appear. That's the system working as intended. Every staff member is assigned exactly one role, and that role quietly shapes the whole workspace — which buttons show up in the top navigation, whether the Save button is enabled, whether you can route or cancel a request, and even whether certain sensitive fields show their values.
This page explains why Aeon looks different for different people, so that when a coworker can do something you can't — or a field reads Restricted instead of showing a value — you understand what's going on and who to ask. You don't configure any of this yourself; an administrator sets up roles in the Customization Manager. This page is about what those roles mean from your seat.
- A menu button or page you expected is missing — your role probably doesn't include that area.
- A button is visible but greyed out, or Save won't enable — you can view that area but not change it.
- You try something and get an Access Restricted screen, or an action quietly fails — your role doesn't grant that level.
- A field shows Restricted with a crossed-out-eye icon instead of a value — that field is hidden from your role.
- You just had your role changed and Aeon asked you to sign in again — that's expected (see When your role changes).
The three things a role controls
Your role decides access along three independent dimensions. Any one of them can be the reason you can or can't do something.
| Dimension | What it controls | What you notice |
|---|---|---|
| Operational capabilities | What you can do in the day-to-day workspace — requests, users, activities, appointments, and so on | Nav buttons appear or disappear; buttons enable or stay greyed out |
| Configuration capabilities | Whether you can open the Customization Manager and which sections of it | The Customization Manager menu, and individual sections inside it, appear or are hidden |
| Field restrictions | Whether specific sensitive fields (for example, date of birth or payment details) are visible to you | Affected fields read Restricted instead of showing the value |
Operational capabilities: what you can do
The bulk of your daily work — requests, users, activities, appointments, the reading room, email, billing, batch processing, web alerts, and exporting data — is governed by operational capabilities. There are ten of these areas, and your role sets a level for each one independently:
| Level | What it means |
|---|---|
| None | You can't see or reach this area at all. Its nav button is hidden; going straight to the URL shows Access Restricted. |
| View | Read-only. You can open lists and records and read everything, but every edit, create, and delete control is disabled. |
| Edit | You can create and change records — save fields, add notes, manage flags, clone, upload attachments, and run the everyday processing actions. |
| Full | Everything in Edit, plus the privileged actions: routing, cancelling, merging, changing a request's site, deleting notes. |
The levels are cumulative: Full includes everything Edit allows, which includes everything View allows. So a check for "can edit" is satisfied by either Edit or Full.
The ten areas, by their on-screen names, are Requests, Users, Activities, Appointments, Reading Room, Email, Batch Processing, Billing, Web Alerts, and Reports & Export. Each is set independently — your role might give you Full on Requests but None on Billing, for example.
What each level looks like in practice
Take Requests as the example, since it's the area you'll use most:
- None — the Requests button is gone from the top navigation, the queue list disappears from the dashboard, and request search (the
#prefix in the command palette) is switched off. If you paste in a link like/requests/12345, you get the Access Restricted screen. - View — you can open queues, browse request lists, and open request #12345 to read every tab (detail, history, notes, emails, attachments). The Lock, Save, and editing controls are disabled — you're reading, not working.
- Edit — now the moment you change a field on request #12345, Aeon locks it for you and Save is live. You can create requests, add notes, manage flags, clone, upload attachments, and run processing actions like Check Out and Place On Hold.
- Full — the privileged actions light up: you can route request #12345 to another queue, cancel it, merge it with a duplicate, or change its site.
The other nine areas follow the same shape. As a rule of thumb across all of them: View lets you look, Edit lets you change, and Full adds the actions you'd want to think twice about — routing, cancelling, merging, deleting, clearing or merging users, confirming or cancelling appointments.
There are two patterns, and they mean slightly different things:
- A whole nav button or menu item is missing → you have None for that area; it's not part of your role.
- A control is visible but disabled (greyed out, or Save won't enable) → you can see the area (View) but your level isn't high enough for that particular action.
Both are working as designed. Neither is a bug — they're your role showing through.
Permissions aren't just hiding buttons in the browser — they're enforced on the server too. If you reach an action your role doesn't allow (by pasting a URL, say), Aeon refuses it rather than half-completing it. There's no "force it through": the answer is to ask an administrator whether your role should include that access.
Configuration capabilities: the Customization Manager
The Customization Manager is the admin area where Aeon itself is configured — queues, email templates, form and print designers, reading rooms, billing rates, staff accounts, roles, and so on. Access to it is separate from your day-to-day operational capabilities, and it's all-or-nothing per section.
If your role has no configuration access, you won't see the Customization Manager entry in the header menu at all. If you have access to some sections but not others, you'll see the menu, but inside it only the sections you're allowed to open appear — and if a whole category has nothing you can reach, its heading is hidden too. As always, going straight to a section's URL without access shows Access Restricted.
This is exactly the line between the two default roles described below: a typical staff member does everything in the workspace but never sees the Customization Manager, while an administrator sees all of it.
Most front-desk and processing staff have no configuration access, and that's by design — configuring queues, templates, and roles is an administrator job. Not seeing the Customization Manager doesn't mean something is broken with your account.
Field restrictions: when a value reads "Restricted"
Separately from what you can do, your role can hide specific field values that are considered sensitive — government IDs, dates of birth, phone numbers and addresses, or billing amounts and payment details, depending on how your administrator has set things up.
When a field is restricted for your role, you still see the field's label, but in place of the value Aeon shows a small Restricted indicator with a crossed-out-eye icon. The data simply isn't sent to your browser — it's removed on the server before the record ever reaches you — so there's no way to reveal it from the page. In custom search, restricted columns are dropped from the results entirely rather than shown as placeholders.
A field that reads Restricted isn't blank — it has a value, you're just not cleared to see it. An ordinary empty field (no Restricted marker) genuinely has no value recorded. If you need a restricted value to do your job, ask an administrator about your role's field restrictions.
The two roles you'll usually meet
Aeon includes two built-in roles that can't be deleted. Your site may add more, but these are the baseline:
| Role | Workspace access | Customization Manager |
|---|---|---|
| Administrator | Everything, at the highest level | Full access to every section |
| Staff | Everything, at the highest level | No access |
The practical difference is just that last column: a Staff member can do anything in the day-to-day workspace but can't open the Customization Manager, while an Administrator can do both. Sites often create additional roles in between — for example, a front-desk role with View on most areas and Edit on a few — but if you're on one of the two defaults, the table above describes you.
A staff account with no role assigned can sign in but can't do anything — every area defaults to None. If you log in and the workspace is essentially empty, ask an administrator to assign you a role.
When your role changes
If an administrator changes your role — or changes what your role is allowed to do — Aeon needs you to sign in again to pick up the new access. You may be signed out automatically and asked to log back in; once you do, the corrected menus, buttons, and fields take effect. This is expected, not an error. (Permission changes can also take a few minutes to reach an already-open session, so signing out and back in is the quickest way to see them immediately.)
You can't change your own permissions from the workspace — there's no self-service toggle, by design. If you think you're missing access you need, the person to ask is whoever administers Aeon at your library (the role that has the Roles & Permissions section of the Customization Manager). Administrators: the configuration side of all of this lives under Customization Manager → Permissions.