Account governance

An account is the top-level container in Lyra: it holds one or more schools and carries a single subscription. This page is the account owner’s reference for everything governed at the account level: the account’s schools, its owners, billing, and renaming or closing the account. For the conceptual model of how the account, school, and library levels nest, see Accounts.

The Account shell

The staff app gives each level its own shell: Account, School, and Library. The Account shell belongs to account owners: anyone else who opens one of its pages is sent to the library or school they last worked in. (For how the shells nest and how the level switcher at the top of the sidebar moves you between them, see Accounts.)

The Account shell has four areas:

• screen: Overview, which lists every school in the account and the libraries inside them.
• screen: Users.
• screen: Billing.
• screen: Settings.

Account owners also carry an status: Account owner badge beside the account name on the Overview, and the owner-only actions below (adding a school, removing a school) appear there for them.

Account owners

An account owner governs the account itself, above any individual school. In the app, owners are the people marked status: Owner at Account level navigation path: Users.

An owner can:

• Manage billing and the subscription (see Billing and the subscription).
• Add and remove schools in the account.
• Manage everyone’s access: make someone an owner, give them a role at any school, or make them a library manager, without being staffed anywhere themselves (see Managing users).
• Turn Vega and semantic search off for the whole account (see Turning AI capabilities off).
• Rename the account, and delete the whole account.

That’s all ownership does. It confers no circulation, roster, or catalog access on its own, an owner who isn’t also staffed in a school can see the account’s structure and manage billing, but can’t run a desk anywhere. Owners who do work in a school carry a separate school role for that, exactly like anyone else.

Owners need not staff any school

An account owner doesn’t have to be staff in any school. A business manager or diocesan IT director can own the account (handle billing, spin up schools) without ever appearing on a school’s staff list. To actually work in a school, they’d be added as staff there too.

Account ownership and school staffing are independent: 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 school-side access model (roles and the library-manager grant) is covered on Staff users.

Managing users

Everyone in the account, and everyone invited to it, is listed at Account level navigation path: Users, which only owners can open. Each row shows whether the person owns the account, as status: Owner or status: Member under field: Account, and their roles under field: Staffing: one chip per school with their role there and the libraries they manage at it (with one school in the account, the chip leaves the school’s name off). Someone with a pending invite reads status: Pending invite under their name, or in its place if they were invited without one. Filter the list by field: School, field: Account, or field: Status; status: Not staffing finds owners who staff no school.

• Add someone. Select button: Add user, enter their email and, optionally, their name, then choose what they get: switch on field: Account owner, pick a role at any school from the select beside it (status: Not staffing, Limited, Standard, or Admin, each with a line saying what it allows), and switch on any of that school’s libraries under field: Library manager, which appear once the school has a role. Any combination works, as long as there’s at least one. Someone already in this account (an owner, or staff at any of its schools) gets the change immediately and one email summarizing it. Anyone else gets one invitation listing all of it, including someone who already uses Lyra with another organization.
• Change someone’s access. Choose menu item: Edit access… from the row’s menu. Setting a school’s role to status: Not staffing takes them off that school’s staff. A pending invite is edited the same way.
• Change your own access. menu item: Edit access… works on your own row too, so you can staff yourself at any school, or give a role back that you gave up. Your own field: Account owner switch is locked there; giving up ownership is its own action, below. Taking away your own admin role or school asks you to confirm first.
• Remove someone. Choose menu item: Remove and confirm with button: Remove user. They lose ownership and their role at every school at once. An account must keep at least one owner, so the last owner can’t be removed. To give up your own ownership, choose menu item: Remove myself as owner on your own row and confirm with button: Remove myself; Lyra then takes you out of the Account shell, into a school you still staff if there is one.
• Pending invites have menu item: Resend and menu item: Revoke in the same menu. Revoking withdraws the whole invite.

Each person has at most one pending invite per account, and it lists everything they’ve been offered there. They open the emailed link and sign in, then tick the box agreeing to the Terms of Service, Privacy Policy, and Data Processing Agreement and select button: Accept invite once to take all of it. Lyra lands them in the school they were given, or on Account level navigation path: Overview if the invite gave them ownership and no school.

Being an owner does not make someone staff in any school, and removing ownership doesn’t touch their school roles. The two are set separately, even though one dialog sets both.

This page is also the recovery path for a school left with no admins, a state Lyra allows: an owner can make anyone an admin there, who then takes over the school’s staff, libraries, and roster from the inside. What a school admin can actually do is covered on Staff users.

Adding a school

A school joins an existing account rather than standing on its own. Account owners add one from the account Overview:

1. From the screen: Overview, select button: Add a school. (Only account owners see this.)
2. Enter the school’s name, the grade range it serves, and who administers it (you’re included by default), then select button: Add school.
3. The school is created under the same account and the same subscription. If you made yourself an admin, Lyra drops you into the new school so you can add its first library.

Schools share the account, not their data

A new school joins your account’s existing billing, there’s no second subscription. But the schools are otherwise independent: each has its own libraries, patrons, catalog, calendar, and staff, and they don’t share that data. A single school is all most institutions need; multiple schools are for a genuine multi-campus or diocesan setup. See Schools.

A brand-new account, with its first school and library, is created by the onboarding wizard the first time you sign up, not from this button.

Libraries on the Overview

Each school on the Overview lists its libraries as cards. If you staff the school, select a library’s card to open it, or the school’s name to open the school. In a school you don’t staff, the cards and name show without links.

A school admin also manages the school’s libraries from here, the same as on the school’s own Libraries page: button: Add a library adds one, and each card’s actions menu (row action: ⋯) has menu item: Manage managers…, menu item: Rename…, and menu item: Delete.

Deleting a school

Deleting a school destroys it and everything in it. From the Overview, open the school’s ⋯ menu and choose menu item: Delete school….

This permanently deletes the school

The school and all of its libraries, items, copies, patrons, circulation history, and staff accounts are permanently deleted, and this can’t be undone. The other schools in the account and its billing are unaffected, deleting one school doesn’t change your subscription.

To confirm, type the school’s name into the box and select button: Delete school. An account can drop to zero schools, that’s a recoverable state, and an owner can add one again from the Overview.

Renaming the account

The account’s name appears on billing communications and across the Account shell. To change it, go to Account level navigation path: Settings, and under card: Profile select button: Edit. Enter a new field: Account name and select button: Save; it can’t be empty.

Turning AI capabilities off

Some schools and districts have a policy against sending data to an AI service. An account owner can turn Lyra’s two AI capabilities off separately: go to Account level navigation path: Settings, and use the switches under card: AI Capabilities. Each applies to every school and library in the account at once, and a school can’t turn one back on for itself. With both off, nothing from the account is sent to an AI service.

Vega

setting: Vega AI assistant controls Vega, which runs on Anthropic. While it’s off:

• Vega disappears from every library: the sidebar, search, and the ask-Vega link on a failed import. Opening a Vega link someone saved goes to the library dashboard instead.
• Call numbers are suggested only from your own copies. When you add a copy to an item whose copies already share a call number, Lyra still fills it in; otherwise the field is left for you.

Everyone’s Vega conversations are kept, out of sight, and come back when an owner turns Vega on again.

Semantic search

setting: Semantic search controls finding items by meaning, which runs on OpenAI. While it’s off:

• OPAC search matches words only. Searching by title, author, series, topic, or ISBN works as before, but a search no longer finds items by meaning, and an item’s card: More like this section is hidden.
• Vega answers without similarity or grouping. It can still search, count, and break down the catalog, but it can’t find books like one you name or sort the collection into themes.
• No item is indexed. Items added or edited while it’s off are indexed once it’s back on.

Billing and the subscription

Lyra is billed by patron count, at the account level, with a 30-day trial up front and no credit card required to start. A subscription runs for a one-, two-, or three-year term, is billed once per term, and renews at the same length; longer terms carry a prepay discount. One account carries one subscription, no matter how many schools are inside it, and the patron-count tier is measured across every school in the account combined.

Billing and the subscription are managed by account owners: Account level navigation path: Billing and the Stripe Customer Portal are visible only to owners, not to school admins or other staff.

Choosing a plan

During the trial, after a trial ends, and after a subscription is canceled, navigation path: Billing is a plan picker in four steps. Each step opens once the one above it is answered, and nothing is chosen for you.

1. card: Choose Your Plan: pick a patron-count tier and a term. A tier smaller than your current patron count can’t be picked, and the Custom tier is quoted, so it links to support instead.
2. card: Pick Your Renewal Month: pick the month the subscription renews in. The first payment covers today up to that renewal, so the month also sets what you pay today.
3. card: Choose How to Pay: choose setting: Pay by card to pay through Stripe Checkout, or setting: Pay by invoice (PO) to be emailed a net-30 invoice. Confirm the field: Billing email, add a field: PO number if your school uses purchase orders, and, if you have one, apply a promo code.
4. card: Review and Confirm: check today’s payment and the renewal’s side by side, select button: Continue, and agree to the auto-renewal terms.

Updating payment, viewing invoices

Once the subscription is active, Account level navigation path: Billing shows the plan, patron usage against the tier, the renewal date, and card: Billing Details. Payment methods, invoices, receipts, and billing details all live in the Stripe Customer Portal, opened from button: Manage in Stripe; the portal is the system of record.

• Payment method. The card on file, or invoicing for a subscription paid by invoice (PO). Change the card at any time; the new card takes effect on the next charge.
• Invoices. Every charge generates an invoice you can download as PDF.
• Receipts. Downloadable for any past period.

PO number

A field: PO number entered when you subscribe is printed on your invoices, so your business office can match each one to its purchase order. It’s optional and works with either payment method; on a card subscription it appears on the invoices behind your receipts.

To add or change it, for example when a new fiscal year brings a new PO, select button: Set PO number (or button: Change PO number once one is set) beside it on the card: Billing Details card, enter the new number, and select button: Save. Leave the field empty and save to remove it. A PO number can be up to 140 characters.

The change applies to invoices created after you save, including your next renewal. An invoice that has already been sent keeps the PO number it was sent with.

An active plan has no in-app upgrade; to move to a larger tier, contact support. If a renewal payment fails, navigation path: Billing shows the retry schedule and button: Update payment method.

If your school requires a W-9 or a vendor setup form, contact support@lyralibrary.com; we’ll send the paperwork.

Over the patron limit (read-only mode)

An active subscription whose patron count exceeds its tier cap enters read-only mode. This is separate from the paused state of a lapsed trial or a cancellation, the subscription is current; the count is just over.

Read-only mode goes by the account-wide count, which sums every school under the account, so it applies to every school and library in it, not just the one that grew. In the Account, School, and Library shells a red status: Action needed banner reads message: Your account exceeds its patron limit (240/200). The app is in read-only mode. followed by message: Reduce your patron count or visit billing to upgrade. for an account owner, or message: Reduce your patron count or contact an account owner to upgrade. for everyone else. The banner compares the same account-wide count the block itself goes by, so a school that is under the cap on its own still shows it when a sibling school pushes the account over.

Viewing data still works everywhere. Actions that change data are rejected: adding or editing patrons, homerooms, and rosters; circulation (check-out, check-in, renewals); placing and filling staff-side holds; and edits to library settings, policies, and the catalog.

Getting a copy of the catalog out still works. From navigation path: Catalog then Items and its Copies tab, exporting to Excel, CSV or MARC and printing labels both run — on a filtered list or a checked selection — as does the inventory to-scan export. They read the catalog and write nothing, so read-only has no reason to stop them.

Roster and circulation exports are the exception and stay blocked: patron exports and card printing, the pull and re-shelve CSVs, the homeroom export, the active-loan export and its overdue notices, and the inventory report.

Two kinds of action stay available, so you can always get back under the cap:

• Reduce the count. Delete or merge patrons, delete roster data, or run a roster import or sync that prunes departed students. Connecting a new roster integration stays blocked, since its first sync usually adds the whole roster.
• Resolve billing. View the subscription, preview pricing, apply a promo code, and open the Stripe portal. Moving to a higher tier goes through support.

Exempt actions still respect access: the roster edits above (deleting, merging, importing, syncing) need an admin, and billing actions need an account owner. A non-admin or non-owner user is pointed to the right person.

Cancelling a hold is exempt too, on both sides of the desk: a librarian can cancel a hold from the Ready, To Pull, item, patron, or copy pages, and a patron can cancel their own from the OPAC. Nobody should be stuck in a queue they can’t leave because of a billing state, and cancelling shrinks the shelf rather than growing it.

The OPAC stays up, and patrons keep signing in, browsing, and searching. New holds are the exception: read-only applies to the OPAC as well, so button: Place hold is hidden on every item and the note reads message: This library isn't taking holds right now. Cancelling an existing hold still works, so nobody is stuck in a queue they can’t leave. Background jobs keep running too: scheduled roster syncs, due-soon and overdue notices, and hold-lifecycle processing.

Cancelling

Cancellation runs through the Stripe Customer Portal, linked from Account level navigation path: Billing. There’s no in-app cancel button.

What happens on cancel:

• Nothing changes right away. Cancelling stops the subscription from renewing, it doesn’t pause the account on the spot. You keep full access for the rest of the period you’ve already paid for, and the OPAC stays available to patrons. Once it’s scheduled, navigation path: Billing reflects it: the plan card’s message: Renews becomes message: Ends with the date the subscription runs out. Stripe also emails you a confirmation.
• At the end of the paid period the subscription ends and the account is paused: the staff app goes read-only, and the OPAC stops loading entirely — patrons get message: This catalog is currently unavailable. This is stricter than a lapsed trial, where the catalog stays browsable and only holds are blocked.
• Data retention. When the subscription ends it starts a 30-day grace period. During it the account is only paused, resolve billing to reactivate, and everything comes back. After 30 days the account and all its data are permanently deleted across every school in it: patrons, items, circulation history, holds, and uploaded files. This can’t be undone. Account owners get a warning email at least 14 days before deletion, and a confirmation once it’s done.
• Data export. Export anything you want offline copies of (patron list, item list, circulation history) before the grace period ends, once the account is deleted there’s nothing left to recover. The exports on the relevant pages cover these.

Prepaid time you haven’t used is not refunded by default, but if you have an unusual circumstance (school closure, district-wide change), get in touch.

Deleting the account

Closing the account for good is Account level navigation path: Settings, in the card: Delete Account card, then button: Delete account. It deletes every school in the account, all their libraries, items, copies, patrons, circulation history, and staff accounts. This can’t be undone. To confirm, type the account name and select button: Delete.

Cancel the subscription first

You can’t delete an account while its subscription is active or status: Past due and still set to renew. The dialog opens saying message: This account has a subscription., with the name box and button: Delete turned off. End it from the Stripe portal linked from Account level navigation path: Billing (see Cancelling).

You don’t have to wait out the paid period after that. As soon as the cancellation is scheduled, the dialog lets you delete: it names the date the subscription would have ended and warns that deleting now cancels it outright, so access ends immediately rather than at the end of the period. Prepaid time you give up this way isn’t refunded. The button also works during a trial, after a trial ends, and once the subscription has ended; any remaining subscription is canceled as part of the deletion.

There are two ways an account ends up deleted:

• You delete it from the card: Delete Account card, as above, it disappears from your account list immediately once confirmed.
• It lapses. If a trial ends, or a cancellation runs its course, without billing being resolved, the account is paused and then, after the 30-day grace period, permanently deleted automatically. See Cancelling for that timeline and how to export your data first.

See also

• Accounts and Schools — the structure all of this sits on.
• Staff users — the school-side access model: roles and the library-manager grant.
• Onboarding — the wizard that creates a brand-new account and its first school.