Staff users

Lyra distinguishes users (people who sign in to the staff app) from patrons (people who borrow). The same human can be both, but they are separate records. This page covers the school-side access model (the roles and grants that let people run a school) and the actions for managing it.

Access sits at two independent levels:

School staff run a school, circulation, roster, catalog, settings. Each staff member carries one role (Admin, Standard, or Limited) and an optional per-library library-manager grant. Managed under School level navigation path: Staff. This page covers all of it.
Account owners govern the account above the schools, billing, the subscription, and the set of schools. That account-level layer lives on Account governance, not here.

The two don’t imply each other: an account owner is not automatically a school admin, and a school admin is not automatically an account owner. A small school typically has the same one or two people wearing both hats; a diocese might keep them entirely separate.

The sections below describe what each role is for. For the capability-by-capability breakdown — which role can do exactly what — see Staff permissions.

User vs. patron

A user is a staff account in Lyra. Users sign in to the staff app via Google, Microsoft Entra, or a 6-digit code emailed to them. There are no passwords.
A patron is a borrower. Patrons may sign in to the OPAC by various methods library managers can configure. They have a type (Student or Faculty) and may belong to a homeroom.

The same person can be both. A librarian who also borrows books from their own library has a user account for the staff app and a patron record for borrowing. They have separate sign-in flows, and updating one doesn’t update the other.

Account owners

Account ownership is a separate, account-level layer: owners handle billing, the subscription, and the set of schools, and they manage everyone’s access across the account, school admins included. Ownership grants no circulation, roster, or catalog access on its own. It’s covered in full on Account governance, including managing users. The rest of this page is the school-side model.

School staff roles

Every staff member of a school carries exactly one role, chosen from a single field: Role selector when you add them. The roles are cumulative, each includes everything below it:

Admin

Administers the school. On top of everything a Standard member can do, an admin can:

Edit the roster, add, edit, delete, and merge patrons; create and manage homerooms; assign barcodes across the roster; import roster files; and connect and configure roster sync (SIS integration).
Manage staff, add and remove staff, change anyone’s role, and grant or revoke library-manager.
Manage libraries, create, rename, and delete libraries in the school.
Manage library managers, choose who manages which library.
Edit school settings, name, logo and color, grade range, the school calendar (academic year start and holidays), and the permanent-deletion actions.

An admin has baseline circulation like any staff member and the full roster visibility a Standard member has; the admin role adds roster editing and the school-management powers on top. Admin is school-scoped, it governs this school, not billing or the set of schools (that’s account owners).

Standard

The operational baseline, for faculty and librarians who facilitate library services. A Standard member can, in any library of the school:

Check out, check in, and renew.
Fulfill and manage holds in queue order.
See loan history on a patron, an item, or a copy.
Export roster data (patrons, homerooms) to CSV.
Open roster sync and read its runs and warnings.
Send a hold-ready, due-soon, or overdue notice on demand.

Standard is full roster visibility. What it doesn’t include is roster editing (adding, editing, deleting, or merging patrons, managing homerooms, importing, or configuring sync, which are all admin-only), nor school management (staff, libraries, settings) or the catalog/policy/OPAC controls. Changing a patron’s barcode is roster editing, so it is admin-only too.

Limited

Restricted visibility of circulation history, for volunteers and helpers who run the desk but shouldn’t see what a student has borrowed. A Limited member can:

Check out, check in, and renew.
Fulfill and manage holds in queue order.

A Limited member runs the desk on exactly the same baseline as Standard. What the role takes away is checkout history, contact details, bulk export, and roster sync: the history tab on a patron, item, or copy; the button: Checked Out By column on the Check In feed, so a volunteer sees what came back without seeing who brought it; a patron’s email and guardian emails, wherever they would otherwise appear; row selection and CSV export on the roster; the navigation path: Roster then Sync pages; and sending notices on demand. (Roster editing is admin-only for everyone, so it isn’t what separates Limited from Standard.)

Contact details and history travel together because they answer the same kind of question — who this student is outside the desk, rather than what they have out right now. A Limited member still gets everything the desk itself needs: the patron’s name, barcode, homeroom, grade, and OPAC PIN, because helping a student who has forgotten their PIN is exactly the volunteer’s job.

The library-manager grant

Separate from the role, a staff member can be granted library manager for one or more specific libraries. It’s a per-library grant, a user can manage one library in the school and not another, and it stacks on top of any role.

A library manager has the elevated operational authority for that library:

Catalog, full control of items, metadata, and weeding.
Circulation policies, create, edit, and delete item policies, grade-level overrides, and faculty overrides, and set the library’s circulation defaults. (Configuring limits that apply to patrons by type or grade is library management, not a roster edit.)
OPAC, configure and manage the library’s OPAC, including its web address.
Overriding circulation actions beyond the baseline:
- Change hold priorities (reorder the queue).
- Un-assign a copy from a ready hold, reverting it to un-ready.
- Override the due date away from the policy-calculated value.

Library manager does not include roster editing or the library lifecycle (create, rename, destroy), those belong to the school admin.

How role and grant combine

The role sets roster and management authority; the library-manager grant adds catalog and desk-override authority for specific libraries. Every staff member has baseline circulation in every library of the school regardless.

Role	Library manager	Who they are
Limited	✗	Volunteer / helper: runs the desk; limited patron PII and no circulation history.
Limited	✓	Catalog / tech-services helper: manager powers (catalog, policies, OPAC, overrides) but still no PII, history, or roster pages.
Standard	✗	Circulation + roster staff: baseline circulation plus full roster visibility (view, export, history) and credential setting; no roster editing (admin-only), no catalog/policy/OPAC, no overrides.
Standard	✓	Librarian: full roster visibility plus all manager powers for the libraries they run; roster editing and school management still require admin.
Admin	✗	School administrator: staff, libraries, and settings, plus roster editing and baseline circulation; not a desk manager.
Admin	✓	Head librarian: school management, roster editing, and manager powers. Everything inside the school.

Staff permissions breaks each of these rows down capability by capability.

Layer account ownership on top of any row when the same person also governs billing and the set of schools. None of these rows is an account owner by virtue of their school role, ownership is granted separately.

Scope: account, school, library

The three pieces sit at three scopes, which is why they coexist instead of conflicting:

Account ownership is account-scoped. It applies to billing and the whole set of schools.
The role is school-scoped. A user holds one role per school; the same person can be Admin in one school and Standard in another.
Library manager is library-scoped. The same user can manage one library and not another within a school.

A diocese with three schools under one account might run:

Diocesan IT director. Account owner; handles billing and adds the schools. Not staff in any school unless they also need a desk.
Lower School librarian. Admin in the Lower School, library manager there. Runs that school and its desk; has no access to the other schools.
Volunteer parent. Limited role at one school, no library-manager grant, not an owner. Runs circulation, sees no student PII.

Inviting a staff user

Admins add staff at School level navigation path: Staff, then button: Add staff. (Adding staff is an admin action; non-admins don’t see the control.)

The flow:

Enter the user’s email address, both their sign-in identifier and where any invitation lands.
Pick their role at this school from the select beside its name: Admin, Standard, or Limited; each option describes itself. See School staff roles.
Once the school has a role, its libraries appear under field: Library manager. Switch one or more on to make them a library manager there. It’s a per-library grant, independent of the role. If you also own the account, the dialog offers field: Account owner too.
Confirm with button: Add staff. If the person is already in your account (an account owner, or staff at any of its schools) they’re added immediately and emailed a summary of the change. Anyone else, including someone who uses Lyra with another organization, gets an emailed invitation to accept. If they already have a pending invite to your account, the new role is added to that invite instead, and no new email goes out; use menu item: Resend to send it again.
The new user opens the emailed link and signs in via Google, Microsoft, or a 6-digit email code. There is no password step. The invitation then opens: they tick the box agreeing to the Terms of Service, Privacy Policy, and Data Processing Agreement, and select button: Accept invite.

There is no provisioning API and no bulk-import path for staff users. Each user is added individually.

Changing someone’s role or libraries

Under School level navigation path: Staff, open a staff member’s row action: ⋯ menu and choose menu item: Edit… to change their field: Role or their field: Managing libraries at any time, then select button: Save. The change takes effect on their next page load.

Because the role is a single setting, moving someone between full and restricted roster visibility is just a matter of switching them between Standard and Limited, there’s no separate roster-access toggle.

Removing a staff user

To remove a staff user, open their row’s row action: ⋯ menu under School level navigation path: Staff, choose menu item: Remove, and confirm with button: Remove staff.

What happens:

The user is removed from the school’s staff and can no longer access that school. Their existing sessions for it are invalidated.
Their patron record (if they have one) is not affected. Staff and patron records are separate.
Records they created stay in place. Loans, holds, item edits, patron edits, override events all retain the original author’s name.

Removal is a hard delete of the school staff membership; there’s no soft-delete. If the same person returns later, add them again; their previous role and library-manager assignments are not preserved. For a pending invitation that hasn’t been accepted, the row’s menu offers menu item: Revoke instead, confirmed with button: Revoke invitation.

Changing your own role away from Admin, or removing yourself, asks you to confirm first and says who can give the access back: you, from the account’s screen: Users page, if you own the account; otherwise another admin at the school or an account owner. It also warns you when you’re the school’s last admin.