FOLIO Documentation – Platform Essentials

Docs: Item status

Mon, 01 Jan 0001 00:00:00 +0000

FOLIO is implementing a three-part item state function. The three factors are Availability; Needed for; and Process.

Once developed, the three factors for item state will interact to drive functionality, and display status information on the item record. For example, an item that has an Availability value of “Checked Out” and a Needed for value of “Reserves” might trigger a process that routes the item to Course Reserves staff when returned, and prevent other patrons from requesting the item in the meantime.

Only Availability is currently implemented. In various FOLIO apps, it is labeled Item status.

Availability

An item’s availability provides information about an item’s location and whether it can be circulated. In FOLIO, availability is currently labeled Item status.

Availability is a required value for an item. You cannot edit it directly. FOLIO processes, such as data import, ordering an item, checking an item in, or marking an item missing, set the availability value.

An item’s availability controls whether it can be loaned and whether it can be requested, even if the applicable circulation rule would otherwise allow the item to circulate.

Needed for

Needed for is not yet implemented in FOLIO.

When implemented, Needed for will allow libraries to assign a workflow for an item to follow to meet specific staff or patron needs. Some examples where Needed for might be used include item requesting; placing items on course reserve; or sending an item for binding. Needed for will be an optional value.

Process

Process is not yet implemented in FOLIO.

When implemented, Process will describe a staff process that an item is in. Common processes might include Digitization; Item Repair; or Cataloging. Process will be an optional value.

How Item Status Changes During Circulation

If a FOLIO library relies on an item’s status to inform patrons and control how that item is used, library staff should be aware of how item statuses change as part of circulation (requesting, check out, and check in.)

When a patron requests an item, the item status may change to Paged, or, if the item is currently on loan, it may change to In transit when the item is returned.
When a patron checks out an item, the item status will change to Checked out.
When an item is checked in, the item status may change to Available or In Transit, depending on the status it has or where it is located when it is scanned in the Check In app.

Items in some statuses will warn library staff members that the item status is going to change, and ask them to confirm check in before proceeding.

Item statuses do not automatically revert

Importantly, FOLIO does not automatically reset an item status to what it was before it circulated. If your library uses item status to communicate information about an item, and then the item circulates, you will need to develop workflows to manually restore the item’s status once it is returned.

For example:

Suppose a library decides to use the item status Restricted to indicate that a certain collection should only be used if patrons are pre-approved for access. If the library staff member then checks out an item with a Restricted status to an approved patron, the status of that item will change to Checked out.

When the item is checked in, the status will change to Available or In Transit; FOLIO will not automatically change the status to Restricted. The library would need to use reporting tools or other workflows to identify the item when it is returned and change the status back to Restricted.

Currently implemented item statuses

Item Status Name	Description	Apps that use this item status	Can this status be set in Inventory?	Can the item be checked out?	Can the item be requested?	Can the item be deleted in inventory?
Aged to lost	The item was borrowed by a patron who did not return it; after a defined time frame, the item is marked Aged to lost and the patron is usually charged to replace the item.	Aged to lost is set automatically by FOLIO system processes and cannot be manually set in Inventory.	Aged to lost cannot be manually set in Inventory.	An Aged to lost item cannot be checked out; this restriction cannot be overridden.	An Aged to lost item cannot be recalled, placed on hold, or paged.	An Aged to lost item cannot be deleted in Inventory.
Available	The item is ready for circulation.	An item can be marked Available by the Inventory, Check In, or Data Import apps. The Inventory app automatically sets an item as Available if an item record is created manually in the app.	Available cannot be manually set in Inventory after initial item creation.	An Available item can be checked out; when that occurs, the item status changes to Checked out.	An Available item cannot be recalled or placed on hold; it can be paged.	An Available item can be deleted in Inventory (subject to dependencies check).
Awaiting delivery	The item has been requested for delivery, but is not yet checked out to the patron and is in the delivery process. This item status generally indicates a problem with delivery; an item that is out for delivery will have a status of Checked out.	Awaiting delivery is set by the Check in app.	Awaiting delivery cannot be manually set in Inventory.	An Awaiting delivery item can be checked out; when that occurs, the item status changes to Checked out.	An Awaiting delivery item can be recalled and can be placed on hold; it cannot be paged.	An Awaiting delivery item cannot be deleted in Inventory.
Awaiting pickup	The item has been requested and is now at the pickup location, waiting for the requester to borrow the item.	An item is marked Awaiting pickup by the Check in app.	Awaiting pickup cannot be manually set in Inventory.	An Awaiting pickup item can be checked out; when that occurs, the item status changes to Checked out.	An Awaiting pickup item can be recalled and can be placed on hold; it cannot be paged.	An Awaiting pickup item cannot be deleted in Inventory.
Checked out	The item is on loan to a patron.	An item is automatically marked Checked out by the Check out app only.	Checked out cannot be manually set in Inventory.	A Checked out item is already in a checked out state; trying to check it out again will be prevented.	A Checked out item can be recalled and can be placed on hold; it cannot be paged.	A Checked out item cannot be deleted in Inventory.
Claimed returned	A patron borrowed the item and has told the library that they returned the item, but there is no record in FOLIO of the item being returned. Libraries can use the Claimed returned item status in workflows while they search for the item.	An item can be marked Claimed returned in the Users app.	Claimed returned cannot be manually set in Inventory.	A Claimed returned item cannot be checked out; this restriction cannot be overridden.	A Claimed returned item cannot be recalled, placed on hold, or paged.	A Claimed returned item cannot be deleted in Inventory.
Declared lost	A patron borrowed the item and has told the library that they will be unable to return the item. Generally, this is used when a patron has lost an item or it has been damaged beyond repair, but the patron does not want to wait for the item to age to lost automatically.	An item can be marked Declared lost in the Users app.	Declared lost cannot be manually set in Inventory.	A Declared lost item cannot be checked out; this restriction cannot be overridden.	A Declared lost item cannot be recalled, placed on hold, or paged.	A Declared lost item cannot be deleted in Inventory.
In process	The item has been received at the library, but is not yet ready to circulate.	An item is automatically marked In process when it is received through the Receiving app. Items can also be marked as In process in the Inventory or Data Import apps.	In process can be applied in Inventory, depending on the item status the record is being changed from.	An In process item can be checked out; when that occurs, the item status changes to Checked out.	An In process item can be recalled and can be placed on hold; it cannot be paged.	An In process item can be deleted in Inventory (subject to dependencies check).
In process (non-requestable)	The item is being worked on by library staff. Patrons cannot request it.	An item can be marked In process (non-requestable) in the Inventory or Data import apps.	In process (non-requestable) can be applied in Inventory, depending on the item status the record is being changed from.	An In process (non-requestable) item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When that occurs, the item status changes to Checked out.	An In process (non-requestable) item cannot be recalled, placed on hold, or paged.	An In process (non-requestable) item can be deleted in Inventory (subject to dependencies check).
In transit	The item is currently moving between two service points.	An item is automatically marked In transit by the Check in or Data import apps. If an item is marked In transit by Data import, no service point information will display in the Inventory app.	In transit cannot be manually set in Inventory.	An In transit item can be checked out; when that occurs, the item status changes to Checked out.	An In transit item can be recalled and can be placed on hold; it cannot be paged.	An In transit item can be deleted in Inventory (subject to dependencies check).
Intellectual item	The item is a placeholder or dummy record; a physical item does not exist. Libraries can use this for electronic item records, for analytics management, or for any scenario where they need an item record for something that does not physically exist.	An item can be marked Intellectual item in the Inventory or Data import apps.	Intellectual item can be applied in Inventory, depending on the item status the record is being changed from.	An Intellectual item cannot be checked out; this restriction cannot be overridden.	An Intellectual item cannot be recalled, placed on hold, or paged.	An Intellectual item can be deleted in Inventory (subject to dependencies check).
Long missing	The item is not on loan to a patron and cannot be located. This status can be used with the related item status of Missing to allow libraries to do several searches for an item before declaring it withdrawn.	An item can be marked Long missing in the Inventory or Data Import apps.	Long missing can be applied in Inventory, depending on the item status the record is being changed from.	A Long missing item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When the checkout occurs, the item status changes to Checked out.	A Long missing item cannot be recalled, placed on hold, or paged.	A Long missing item can be deleted in Inventory (subject to dependencies check).
Lost and paid	This item was borrowed by a patron who did not return it; the item was marked declared lost or aged to lost. The library and patron then resolved the associated fine.	Lost and paid is set automatically by FOLIO system processes and cannot be manually set in an app.	Lost and paid cannot be manually set in Inventory.	A Lost and paid item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When the checkout occurs, the item status changes to Checked out.	A Lost and paid item cannot be recalled, placed on hold, or paged.	A Lost and paid item can be deleted in Inventory (subject to dependencies check).
Missing	The item is not on loan to a patron and cannot be found. This status is generally used if the library is still searching for the item or waiting to see if it reappears.	An item can be marked Missing in the Inventory or Data import apps. A Claimed returned item can be marked Missing in the Users app.	Missing can be applied in Inventory, depending on the item status the record is being changed from.	A Missing item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When the checkout occurs, the item status changes to Checked out.	A Missing item can be placed on hold; it cannot be recalled or paged.	A Missing item can be deleted in Inventory (subject to dependencies check).
On order	The item has been ordered, but has not yet been received.	An item is automatically marked On order by the Orders app when the order creates an item record. It can also be marked On order in the Data Import app.	On order cannot be manually set in Inventory.	An On order item can be checked out; when that occurs, the item status changes to Checked out.	An On order item can be recalled and can be placed on hold; it cannot be paged.	An On order item cannot be deleted in Inventory.
Order closed	The order associated with the item was closed and the item was not received.	An item is automatically marked Order closed by the Orders app if an order is closed and the item is not yet received. It can also be marked Order closed in the Data import app.	Order closed cannot be manually set in Inventory	An Order closed item can be checked out without a warning. When the checkout occurs, the item status changes to Checked out.	An Order closed item can be placed on hold; it cannot be recalled or paged.	An Order closed item can be deleted in Inventory (subject to dependencies check).
Paged	The item had a status of Available and was then requested by a patron.	Paged is set automatically by FOLIO system processes and cannot be set manually in an app.	Paged cannot be manually set in Inventory.	A Paged item can be checked out; when that occurs, the item status changes to Checked out.	A Paged item can be recalled and can be placed on hold; it cannot be paged since it already has a Paged status.	A Paged item cannot be deleted in Inventory.
Restricted	The item is available, but the library wants to indicate that there are limits on its access.	An item can be marked Restricted in the Inventory or Data import apps.	Restricted can be applied in Inventory, depending on the item status the record is being changed from.	A Restricted item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When that occurs, the item status changes to Checked out.	A Restricted item can be recalled, placed on hold, or paged.	A Restricted item can be deleted in Inventory (subject to dependencies check).
Unavailable	The item is not available to patrons.	An item can be marked Unavailable in the Inventory or Data import apps.	Unavailable can be applied in Inventory, depending on the item status the record is being changed from.	An Unavailable item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When that occurs, the item status changes to Checked out.	An Unavailable item cannot be recalled, placed on hold, or paged.	An Unavailable item can be deleted in Inventory (subject to dependencies check).
Unknown	The item’s availability is not known.	An item can be marked Unknown in the Inventory or Data import apps.	Unknown can be applied in Inventory, depending on the item status the record is being changed from.	An Unknown item can be checked out; when that occurs, the item status changes to Checked out.	An Unknown item cannot be recalled, placed on hold, or paged.	An Unknown item can be deleted in Inventory (subject to dependencies check).
Withdrawn	The item has been removed from the library’s collection.	An item can be marked Withdrawn in the Inventory or Data import apps.	Withdrawn can be applied in Inventory, depending on the item status the record is being changed from.	A Withdrawn item can be checked out; FOLIO shows a warning to the staff member, and then allows the checkout if the staff member confirms they want to continue. When the checkout occurs, the item status changes to Checked out.	A Withdrawn item cannot be recalled, placed on hold, or paged.	A Withdrawn item can be deleted in Inventory (subject to dependencies check).

Docs: Permissions

Mon, 05 May 2025 00:00:00 +0000

FOLIO has a user role system that allows for granular control over what users can access in their FOLIO installation.

Each app defines its own capabilities for the frontend and backend modules that it uses.

By default, a FOLIO installation does not provide roles or permission profiles for library staff. Instead, FOLIO administrators can build their own groups of roles that correspond to their local needs. They can then assign those roles to users through the Users app.

Managing Roles with Eureka

Overview

The new Eureka platform, which FOLIO is adopting with the Sunflower release, replaces the permission-based access control model from previous releases with a roles-based permission model. This page explains how to manage roles and their assignments. Information on migrating permissions from the Okapi platform to Eureka can be found at the bottom of the page.

Terminology

Permission
- A permission is an object in FOLIO that can be used to control access to FOLIO apps, workflows, and data
- A permission can have a number of different attributes, depending on whether you are viewing the permission in FOLIO’s code or whether you are looking at permissions for a user on a FOLIO tenant
Permission set
- A permission with one or more subpermissions
- Can be nested infinitely
Resource
- Something in FOLIO on which users can perform operations, e.g. orders, instances, etc.
Action
- An operation that manipulates a resource, e.g. create, edit, view, delete, execute, etc.
Capabilities
- Capabilities define the ability to perform an action on a FOLIO resource, e.g. Edit (action) on Instances (resource)
- Derived from information in permissions module descriptors
- Capabilities are managed by the system. Users and admins cannot create or remove capabilities. Instead, they’re created in applications that are enabled for tenants
- They maintain a reference to the permission from which they were created
- They maintain a reference to the application which provides them
Capability sets
- Capability sets are comprised of capabilities
- Derived from information in module descriptors (Permission sets)
- Are managed by the system. Users and admins cannot create or remove capability sets. Instead, they’re created in applications that are enabled for tenants
- Maintain a reference to the permission from which they were created
- Maintain a reference to the application which provides them
Roles
- Comprised of capabilities and/or capability sets
- Created/managed by administrators, not the system
- Cannot be nested. Roles are flat
- Are reusable
Default roles
- Roles provided by the system, optionally loaded during tenant entitlement
Policies
- Provides greater control over who can do what, when, and from where. For example, policies could be created to only allow users to perform check-in/check-out operations during normal business hours from certain locations
- Policies are associated with capabilities
- Time-based policies are managed by administrators, not by the system
AuthUser
- Refers to a user record in Keycloak
- AuthUsers are managed by FOLIO. No direct interaction with Keycloak is required
- AuthUsers are a subset of Users, which include staff, patrons, administrators, etc.
- A user becomes an AuthUser if they are assigned credentials, roles, or capabilities. The Keycloak user record is only needed for those who log in and use FOLIO. There is no need for Keycloak to know about patrons and others who are just data in the system

How do these relate to one another? This diagram may help you visualize the relationships between some of these terms:

Role Creation

Role creation happens in the “Authorization Roles” section of Settings. Use the “+New” button in the upper right corner to open the form for creating a role.

Provide a name and description, then use the “Select application” button to open the selection modal. The purpose of selecting applications is to specify the functional areas which provide capabilities and capability sets you want to add to the role. Only Capabilities and Capability Sets provided by the selected application(s) will be shown.

After selecting one or more applications and clicking “Save and close,” the Capability and Capability Set portions of the role creation form will be populated, and you can select those which you want to include in your role by checking individual boxes or the boxes in the column headers.

Notes on selecting Capabilities and Capability Sets:

Capabilities and Capability Sets are divided into 3 groups: Data, Settings, and Procedural. These are intended to make it easier to sort through the options. Here are brief descriptions of each set:
- Data: Capablities for directly managing resources as they exist in FOLIO (i.e. RESTful APIs) *E.g. “Instance,” “purchase order lines,” etc.
- Procedural: Capabilities for initiating and controlling processes in FOLIO (i.e. execution of tasks) *E.g. “Check-out-by-barcode”
- Settings: Administrative Capabilities for managing FOLIO configurations *E.g. “Notes settings”
Selecting a Capability Set will result in the automatic selection of its constituent capabilities. You cannot unselect individual capabilities which were automatically checked
Tip: Using “find on page” (e.g. Ctrl+F / Cmnd+F) can be helpful when searching for capabilities
Don’t forget to click “Save & close” when you’ve made your selections

Role Modification

Making adjustments to roles is very similar to creating new roles. Start by selecting the name of the desired role. This will result in a detail pane to be displayed.

Tip: the search bar can help you find what you’re looking for.

Use the “Actions” menu in the role details pane to select “Edit” to alther the role.

The role edit form looks and behaves the same as the role creation form. Refer to the Role Creation section for details.

Role Deletion

Deletion of a role is similar to role modification. Refer to the Role Modification section for details. To delete a role, from the “Actions” menu, select “Delete.” Exercise caution when deleting roles: deleting a role cannot be undone. When deleting a role which is assigned to users, the role assignments will automatically be removed from those users. If you are sure you wish to delete the role, you will be asked to confirm.

Role Duplication

Duplication of a role can be accomplished by following similar steps as role modification. Refer to the Role Modification section for details. However, instead of selecting “Edit” from the “Actions” menu, select “Duplicate.” You will be asked to confirm. A system generated name will be given to the duplicate role. Role assignments will not be copied to the new role.

After confirming you will automatically be taken to the new/duplicate role.

Shared Roles

Shared roles are centrally managed in that they can only be edited in the consortia manager. A shared role will appear as a Role in all tenants with the same capabilities. User from the given tenant can be assigned to that role. Editing that role in the central tenant will change it for all tenants.

To share a role users must have permissions to access the consortia manager app and share data. With your active affiliation set to the systems central tenant. Navigate to Consortia manager -> Authorization Roles.

Select the central tenant from the Member dropdown at the top of the second pane
Choose a Role that you have created in the central tenant
Click the actions menu
Click “Share to all”
When the confirmation modal appears click “Submit” to confirm and share the role with all tenants in the system
You will see a success toast message
In the view pane for the role you will now see “Centrally managed” = Yes

Managing Role Assignments

Role assignments can be maanged from a few different places. Which place is most appropriate depends on what you’re trying to accomplish.

From Settings -> Authorization Roles
- This is a good choice when assigning or unassigning multiple users to/from a given role
From the Users app
- This is a good choice when managing role assignments for a given user
From Consortia manager -> Authorization Roles (only applicable to consortia with ECS enabled)
- From here you can manage role assignments across all related tenants
- From here you can also create “Shared” roles that can be used by all tenants in the system

Settings / Authorization Roles

To manage role assignments in the context of a particular role, navigate to the “Authorization Roles” section of Settings. Start by selecting the name of the desired role. This will result in a detail pane to be displayed.

Tip: the search bar can help you find what you’re looking for.

Once you have selected a role, an additional pane will open showing the details of that role. This role detail pane will include on “Assigned users” accordion (which should be expanded by default).

Clicking on the “Assign/Unassign” button will open the “Select User” modal. Use the facets and search functions to help find the user(s) you want to assign or unassign.

To assign a user to the role, check the box in the first column. To unassign a user from the role, uncheck that box. When finished, click “Save.”

In some cases you may see a dialogue asking you to confirm the creation of user records in Keycloak. The creation of these records is necessary for the role assignment to succeed. Click “Confirm” to proceed, or “Cancel” if you’re unsure.

Upon completion, you will land back at the role detail view. If the assignment (for unassignment) was successful, you should see a green message indicating the success at the bottom of your screen. The “Assigned users” accordion should be updated to reflect the changes you’ve just made.

Users App

To manage role assignments in the context of a particular user, navigate to the “Users” app. Use the facets and search functions to help find the user you want to assign to roles.

Select a user to display that user’s details in a separate pane. Here you will see a “User roles” accordion (collapsed by default). When collapsed, a bubble in the accordion header indicates how many roles the user is presently assigned to. While this accordion is helpful for viewing a user’s role assignments, you cannot edit a user’s role assignments here. Instead, you must select the “Edit” option from the “Action” menu.

On the Edit form, scroll down to and click on the “User roles” accordion to expand it. Here you will see the list of roles this user is assigned to. You can click the “X” icon for a given role to unassign that role. You also have the option to unassign all user roles and add user roles via the buttons below the list or roles.

When using “Unassign all users roles,” you will be prompted to confirm. The roles being removed will be listed in the dialogue box.

When using “Add user roles,” the “Select user roles” modal will be displayed. Use the facets and search functions to help find the role(s) you want to assign to the user. Check the boxes next to the roles you want to assign (or uncheck the roles you want to unassign). When finished, click “Save & close” to submit your changes.

Finally, in order for any of the changes you’ve made to be saved, you must click the “Save & close” button in the user edit form.

N.B. Don’t forget to click “Save & close” on the user edit form to save your changes. If you cancel now, your changes will not take effect.

In some cases you may see a dialgoue asking you to confirm the creation of a user record in Keycloak. The creation of this record is necessary for the role assignment to succeed. Click “Confirm” to proceed, or “Cancel” if you’re unsure.

Upon completion, you will land back at the user detail view. The “User roles” accordion shouild be updated to reflect the changes you’ve just made.

Migration

When migrating from the Okapi platform to Eureka adjustments must be made. Some of this will be handled by migration APIs. Other parts will need to be performed by a human.

Migration APIs

There are two APIs which do most of the heavy lifting. The goal of these is to ensure users who could perform certain actions on Okapi, can still perform those same actions on Eureka.

Users migration - provided by mod-users-keycloak. This API will create AuthUser for any User in the system which has at least one permission assigned to them
Roles migration - provided by mod-roles-keycloak. This API looks at the permissions assigned to users, and creates a Role for each unique set. These system-generated roles are then assigned to the appropriate users
- N.B. Given the high level of nesting in permission sets on the Okapi platform, and the flat roles on Eureka, the migration APIs do not attempt to perform a one-to-one mapping of permission Sets to roles

Post-migration Cleanup

After the migration APIs have been run, human intervention is likely required to clean up system-generated roles. This includes renaming, providing descriptions, splitting, and possibly combining roles. Alternatively, administrators could create roles from scratch, transition to them, and eventually remove the system generated roles.

Docs: Locations

Thu, 09 Nov 2023 00:00:00 +0000

In FOLIO, locations are used to describe where items are located in a library.

Locations are required for any library that wants to use holdings or item records in the Inventory app. Locations are used in workflows with service points, borrowing and returning items, charging fines, requesting items, providing remote storage, and data export for holdings and item records.

The location setup has four hierarchical elements - each level of the hierarchy must have at least one value in order to create a value at the next, more specific level.

Institution. An institution is the highest level of the FOLIO location hierarchy. An institution typically represents entities such as the college or university, though that is not a FOLIO requirement. You can create one or more institutions.
Campus. A campus is the second highest level of the FOLIO location hierarchy, A campus typically represents distinct parts of an institution, like a physical or branch campus, or online programs, though that is not a FOLIO requirement.
Library. A library is the third level of the FOLIO Location hierarchy. A library typically represents physical buildings on a campus, or domains of service on a virtual campus, though that is not a FOLIO requirement.
Location. A location is the fourth and most detailed level of the FOLIO Location hierarchy. A location typically represents specific shelving areas, like the stacks, reserves, or specific language collections, though that is not a FOLIO requirement.

In practice, most libraries represent physical locations in their location tree, but FOLIO does not have a requirement to do so. Libraries can represent locations in a variety of ways.

A library could choose to describe their collection by the physical location of the stacks, such as 3rd Floor, N side, Aisle 1, Side A.
A library could choose to group their locations by administrative structure - for example, one institution with two campuses, one for professional degree libraries and one for undergraduate program libraries.
A library could choose to include their electronic items in their location structure, and have an institution that represents physical items, and an institution that represents electronic items, each with their own campus, library and location structure nested below.

Permanent, temporary and effective locations

In Inventory, you can set permanent and temporary location values on a holdings and/or item record. A holding must have a value set for permanent location.

Using the values in the permanent and temporary location fields, FOLIO computes two effective locations - one on the holdings record, and one on the item record. Libraries do not set the effective location value - FOLIO computes it for them.

Examples

Temporary locations can be used to support various library workflows.

Example 1: Supporting a New Books section of the library

Smith University Library purchases a copy of The Midnight Library by Matt Haig, a popular new book. They want The Midnight Library to be shelved at the “Smith New Arrivals” location for three months, before it gets sent to its permanent location of “Smith Main Stacks.”

When they order the item, library staff set the location on the PO line to “Smith Main Stacks”. This becomes the holdings permanent location for The Midnight Library.
Using Data Import or Inventory workflows, staff then set the item temporary location for The Midnight Library to “Smith New Arrivals”. FOLIO then sets the item effective location to “Smith New Arrivals”, and that location is used by FOLIO when the book circulates.
After The Midnight Library has been circulating for three months, library staff use Inventory or Data Import workflows to remove the item temporary location. That changes the item effective location to “Smith Main Stacks”, and FOLIO uses that location to circulate the item going forward.

Example 2: Supporting a library renovation

Pacific College is renovating their Arts Library. Staff need to move 5,000 items from the Arts Library to the Undergraduate Library during the nine month renovation.

Library staff use Data Import workflows to set a holdings temporary location of “Undergrad Stacks” on the 5,000 holdings records, and then physically move the items.
That changes the item effective location for all 5,000 items to “Undergrad Stacks”, and then FOLIO uses that location as they circulate.
When the renovation is over and the items are returned to the Arts Library, library staff use Data Import workflows to remove the holdings temporary location from all 5,000 items, and that changes their effective locations back to “Arts Library.” FOLIO uses that location to circulate the items going forward.

Configuring Locations

To create the location tree, follow the steps outlined in Settings > Tenant.

Holdings and Item effective locations

FOLIO supports a holdings effective location and item effective location. Both fields are calculated automatically by FOLIO.

Holdings effective location

The holdings effective location is used to provide location information for holdings that are not always itemized, such as periodicals, microfilm, or in-process special collections. It is not used in item circulation workflows.

On the holdings record, there are three location fields:

Holdings permanent location (required)
Holdings temporary location (optional)
Holdings effective location (computed value, set by FOLIO)

FOLIO sets the holdings effective location to the first value it finds in the following list:

Holdings temporary location
Holdings permanent location

Note that if your library is using SRS for MARC Holdings, you will not be able to edit the permanent holdings location field on the inventory record - that will only be editable in quickMARC. You will be able to set a holdings temporary location.

The Holdings effective location is always computed, but it will only display on the holdings detail record if there are no items attached to the holdings.

Item effective location

The item effective location is used by FOLIO to know the current home location for an item, and for staff and patrons to understand where to find an item in the library.

The item effective location is used in multiple apps, including Check out, Check in, Requests, and Users (when viewing loans and fee/fines).

On the item record, there are three location fields:

Item permanent location (optional)
Item temporary location (optional)
Item effective location (computed value, set by FOLIO)

FOLIO sets the item effective location to the first value it finds in the following list:

Item temporary location
Item permanent location
Holding temporary location
Holding permanent location

Note that an item permanent location does not need to be set if the holding permanent location is set. Item effective location is what is used in circulation workflows, and it will inherit the holding permanent location if no location values are set directly on the item. If an item record is moved to a new holdings record, it will inherit its effective location and call number from the holdings record unless it has a temporary or permanent location or call number specified in the item record.

Docs: Keyboard shortcuts

Tue, 07 Jun 2022 00:00:00 +0000

Keyboard shortcuts facilitate actions. For the apps listed below, you can view the available shortcuts while using the app. Note: Most apps do not use all the listed shortcuts. For example, Alt+c does not work in the Users app because you cannot duplicate a record in the Users app.

The action associated with the shortcut may vary slightly for different apps – for example, in the Dashboard app Alt+n is Create a new widget.

Keyboard shortcuts list

Action	Shortcut keys
Create a new record	Alt+n
Edit a record	Ctrl+Alt+e
Save a record	Ctrl+s
Expand or collapse an accordion	Spacebar
Expand all accordions	Ctrl+Alt+b
Collapse all accordions	Ctrl+Alt+g
Go to Search & Filter pane	Ctrl+Alt+h
View keyboard shortcuts list	Ctrl+Alt+k
Duplicate a record	Alt+c
Close a modal or pop-up	Esc
Copy	Ctrl+c
Cut	Ctrl+x
Paste	Ctrl+v
Find	Ctrl+f

Keyboard shortcuts that are only available in one or two app:

Action	Shortcut keys	App used in
Add POL	Alt+a	Orders
Receive pieces/Quick receive	Ctrl+Alt+r	Receiving
Save a piece and create another	Alt+s	Receiving
Edit MARC record	Ctrl+Shift+e	Inventory
quickMARC only: Move to the next subfield in a text box	Ctrl+]	Inventory, MARC authority
quickMARC only: Move to the previous subfield in a text box	Ctrl+[	Inventory, MARC authority

Viewing the keyboard shortcuts list

To view the list of available shortcut keys, follow these steps:

Click on the name of a FOLIO app from the top menu bar. The app opens and the app name displays at the top left of the window.

Click on the downward-facing caret, “v”, at the end of the app name.

Click Keyboard shortcuts to view the list of shortcut actions.

Alternatively, use the keyboard shortcut Ctrl+Alt+k after opening the app.

List of apps displaying the shortcut list

The following apps display the list of keyboard shortcuts which can be viewed by following the steps described above.

Agreements
Claiming
Courses
Dashboard
eHoldings
ERM comparisons
eUsage
Finance
Inventory
Invoices
Licenses
Lists
Local KB admin
MARC Authority
Open access
Orders
Organizations
Receiving
Requests
Serials
Users