Integrated Library Automation System: 7 Workflows to Test Before You Choose

An integrated library automation system links the records and workflows that move materials from selection to reader use. It connects catalogue descriptions, individual copies, patrons, loans, holds, acquisitions, and other supported functions. The value comes from those links: staff should not need to rebuild the same context at every desk.

This article follows seven connected workflows to test when choosing integrated library system software. It covers ordering, cataloguing, patron records, circulation, holds, ongoing resources, and reporting, then examines migration and a practical multi-branch scenario.

What integrated means in library work

A title record describes a work or edition, while an item record can identify a specific physical copy. A patron record identifies a library user. Loans and requests connect those records under local policy.

The Koha manual’s module overview shows functions such as acquisitions, cataloguing, circulation, patrons, and serials. It illustrates the breadth an integrated system can cover without proving that every product offers the same workflow.

A useful evaluation therefore follows records across modules. A strong circulation screen cannot compensate for a lost link between an order, received copy, and public catalogue availability.

1. Selection and acquisition should retain context

Start with how staff choose and order materials. The system may need to record a supplier, fund, order line, expected quantity, and relevant bibliographic context.

When material arrives, staff should connect receipt with the intended order and copies. A partial delivery should leave the remaining quantity visible rather than make the whole order appear complete.

Also test duplicate checking. An existing title or edition may need another copy rather than a new unrelated catalogue record. The system should help staff review that distinction.

Keep financial authority clear. The library’s order record and the finance system’s payment record may serve different roles. If they connect, define the handoff and reconciliation rather than assuming one module replaces the full accounting process.

2. Cataloguing should distinguish description from copy

A bibliographic description, holding, and item can carry different facts. The exact model varies by system, but staff need a reliable way to represent editions, locations, and individual copies.

For example, two branches can hold copies of the same edition with different barcodes and availability. Changing one copy’s location should not change the descriptive identity of every copy.

Use the standards and record practices appropriate to the library’s collection and partners. The responsible cataloguing team should approve mappings and validation rules during migration.

The FOLIO feature overview describes inventory and related library domains. Use product documentation to understand the actual record model, then test it with your own complex materials rather than only a simple book.

3. Patron records should support access and privacy

A patron record needs the identity and contact context required for library services. Avoid collecting extra personal details simply because the system offers fields.

Define categories, permissions, and local policies with library owners. A student, visiting reader, staff member, and community borrower may have different service rights.

Test changed contact details and duplicate records. A merged identity should preserve the required history without attaching one person’s loans to another person by mistake.

Also review staff access. A circulation worker may need a current loan view without access to every administrative or sensitive field. Reports and exports should respect the same privacy decisions as the main interface.

4. Circulation should apply policy consistently

Check checkout, return, renewal, and exception handling as a connected process. The system should identify the patron and specific item, then apply the approved rules.

A rule can depend on patron category, item type, branch, date, and other local factors. Test the combinations the library actually uses. Do not assume a default loan period suits every service.

Make overrides explicit. Authorized staff may need to handle exceptions, but the system should preserve the actor and reason where the policy requires it.

Our broader guide to library management system features provides a starting checklist. For an integrated system, the key extra question is whether circulation uses the same reliable item and patron identities as the other modules.

5. Holds and transfers should track the next action

A hold request can involve a title, a specific copy, pickup location, and queue position under local policy. Define what the request promises and when staff must act.

For a multi-branch library, test an item moving from one branch to another. It should have a meaningful in-transit state rather than appear available at both places or lost between them.

Also test uncollected requests, cancelled holds, and an item returned to an unexpected branch. Each case should leave a clear owner and next step.

Notifications support the process but do not replace it. An email acceptance does not prove that a reader received or collected the item. Keep the hold and pickup state authoritative inside the library workflow.

6. Ongoing resources need their own lifecycle

Serials and electronic resources can have patterns that differ from a single purchased copy. Issues, subscriptions, packages, access periods, and related agreements may need separate records or connected systems.

Choose scope based on the collection. A library with few ongoing resources may need a simpler route than an institution with extensive licensed content. Confirm actual product support rather than infer it from a module label.

Test changes over time. A renewed subscription, missing issue, or ended access period should not become an unexplained gap in the public or staff view.

Also define which external systems own discovery, authentication, or licence details where applicable. Integrated does not have to mean one product owns every function. It means the handoffs and identities remain coherent.

7. Reporting should trace service and collection activity

Useful reports can examine circulation, request waiting time, acquisition progress, and collection status. Define the question and population before accepting a dashboard total.

For example, an unavailable item may be on loan, in transit, under repair, or missing. Combining those states into one count can hide very different actions.

Our article on business intelligence dashboard development explains why measure definitions matter. Apply that discipline to library activity and collection reporting.

Review privacy in analysis. The library may need aggregate use evidence without retaining unnecessary identifiable reading history. The responsible policy owner should define the record and retention needs.

A multi-branch item journey

Imagine a reader requests a title held at another branch. The public catalogue points to the correct descriptive record and available copies under the system’s rules.

The hold enters the appropriate queue with the chosen pickup branch. Staff receive a clear task. When they dispatch a copy, its item record shows in transit rather than on shelf.

At the receiving branch, staff confirm arrival and prepare the item for pickup. The notification process records its known outcome, while the hold record remains the authority for collection status.

Now the reader changes contact details before pickup. The patron update should affect the next permitted communication without losing the request or changing another reader’s record.

Next, the reader checks out the item under the correct policy. A later return at another branch follows the approved routing rule and updates the specific copy’s state.

Finally, a report can trace the request and transfer without inventing duplicate loans or copies. The library can measure waiting and handling using defined states.

This scenario tests the links between modules. It reveals more than separate demonstrations of a catalogue, patron screen, and checkout desk.

Plan migration around record relationships

Inventory bibliographic records, items, patrons, open loans, requests, orders, and other records in scope. Decide what to clean, migrate, archive, or retire.

Keep source identifiers during the migration where reconciliation needs them. A new internal ID should not make staff lose the ability to explain an open loan or supplier order from the earlier system.

Test relationships and status, not only counts. The same number of patrons and items can still hide wrongly linked loans. Open transactions deserve special attention.

Use a rehearsal with representative complex cases. Include duplicate descriptions, missing barcodes, transferred items, partial orders, and local policy exceptions. Library staff should approve the result, not only the migration team.

Review integrations and public access

An integrated library automation system may connect with discovery tools, identity services, finance, self-service devices, or external partners. List each connection and its source of authority.

Our guide to application integration services explains why access, mapping, and recovery belong in that plan. A working connection should preserve meaningful IDs and support an owned failure route.

Test the public catalogue with ordinary users and assistive technology where appropriate. Staff familiarity can hide unclear search labels or request steps.

Also plan service during an outage. Any offline or fallback circulation route needs supported behavior, a clear policy, and later reconciliation. Do not improvise it after the network fails.

Ask suppliers to demonstrate one connected case

Give each supplier the same small safe dataset and local policy examples. Ask them to follow a title from order through receipt, catalogue, hold, transfer, checkout, and report.

Then introduce an exception. A copy may arrive damaged, a patron may lose eligibility, or a branch may close for a day. Watch whether the system preserves context and gives staff a usable next step.

Check permissions, logs, and export options as well as the main workflow. The library needs to support and govern the system after the sales demonstration ends.

Compare total cost, including hosting, migration, training, integrations, support, and future changes. An open-source route can still require substantial operating work, while a hosted product still needs local ownership.

Keep the system aligned with library policy

Assign owners for cataloguing practice, circulation rules, patron data, and technical support. These roles should review changes that affect linked workflows.

A new borrower category or branch rule can alter requests and loans as well as a configuration screen. Test the affected journey before release.

Review recurring workarounds. If staff repeatedly maintain a side spreadsheet to track missing states, the integrated process may need a better configuration or connection.

The goal is one understandable chain of service, with reliable records at each handoff.

Check notices as part of circulation

Ask staff to review a hold-ready notice, renewal result, and overdue message using representative patron data. Confirm the source event, recipient, wording, and link. A correctly recorded loan can still cause confusion if its notice uses the wrong branch or an old pickup instruction.

Then test failed delivery. The request or loan should retain its real state, while staff can find the communication exception and follow the approved policy.

Evaluate integration through the reader’s journey

An integrated library automation system should preserve context from selection to circulation and reporting. Start with one connected case, test its exceptions, and reconcile migrated relationships. Choose a system the library can maintain under its own collection, privacy, and service policies.