This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Platform Essentials

1: Item status
2: Locations
3: Keyboard shortcuts
4: Permissions

In FOLIO, there are several parts of functionality that support library workflows across FOLIO apps. These include:

1 - Item status

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 was 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 as aged to lost and the patron is usually charged to replace the item.	This status is set automatically by FOLIO system processes and cannot be manually set in Inventory.	This status cannot be set in Inventory.	An Aged to lost item cannot be checked out to a patron; 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 as 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.	This status cannot be manually set in Inventory after initial item creation.	An Available item can be checked out to a patron; 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.	This status is set by the Check in app.	This status cannot be manually set in Inventory.	An Awaiting delivery item can be checked out to a patron; 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 is 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.	This status cannot be manually set in Inventory.	An Awaiting pickup item can be checked out to the requesting patron; 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 as Checked out by the Check out app only.	This status 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 and the item cannot be found. 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.	This status cannot be manually set in Inventory.	A Claimed returned item cannot be checked out to a patron; 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.	This status cannot be manually set in Inventory.	A Declared lost item cannot be checked out to a patron; 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 as In process when it is received through the Receiving app. Items can also be marked as In process through the Data Import app.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	An In process item can be checked out to a patron; if 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 (not requestable)	The item is being worked on by library staff and patrons cannot request it.	An item can be marked In process (not requestable) through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	An In process (not requestable) item can be checked out to a patron; when that occurs, the item status changes to Checked out.	An In process (not requestable) item cannot be recalled, placed on hold, or paged.	An In process (not 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 as In transit by the Check in or Data import apps. If an item is marked as In transit by Data import, no service point information will display in the Inventory app.	This status cannot be manually set in Inventory.	An In transit item can be checked out to a patron; 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 through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	An Intellectual item cannot be checked out to a patron; 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 Users app or Inventory app.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	A Long missing item can be checked out to a patron; 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. Once that resolution occurs, the item is marked as Lost and paid.	This status is set automatically by FOLIO system processes and cannot be manually set in an app.	This status cannot be manually set in Inventory.	A Lost and paid item can be checked out to a patron; 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 through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	A Missing item can be checked out to a patron; 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 as On order by the Orders app, when the order creates an item record, or through the Data Import app.	This item status cannot be set in Inventory.	An On order item can be checked out to a patron; if 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 through the Data import app.	This item status cannot be set in Inventory	An Order closed item can be checked out to a patron without 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; the request process changes the item status to Paged.	This status is set automatically by FOLIO system processes and cannot be set manually in an app.	This status cannot be manually set in Inventory.	A Paged item can be checked out to the patron who requested it; 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 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 as Restricted through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	A Restricted item can be checked out to a patron; when that occurs, the item status changes to Checked out.	A Restricted item can be recalled and can be placed on hold; it cannot be 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 through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	An Unavailable item can be checked out to a patron; 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 through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	An Unknown item can be checked out to a patron; 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 withdrawn through the Inventory or Data import apps.	This item status can be applied in Inventory, depending on the item status the record is being changed from.	A Withdrawn item can be checked out to a patron; 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).

2 - Locations

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.

3 - Keyboard shortcuts

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

The following keyboard shortcuts are only available in one app:

Action	Shortcut keys	App used in
Add POL	Alt+a	Orders
Receive pieces/Quick receive	Ctrl+Alt+r	Receiving

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 (this works in all listed apps except for eUsage).

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
Courses
Dashboard
eHoldings
ERM comparisons
eUsage
Finance
Inventory
Invoices
Licenses
Local KB admin
MARC Authority
Orders
Organizations
Receiving
Requests
Serials
Users

4 - Permissions

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

Each app defines its own permissions 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 permissions called permission sets that correspond to their local needs. They can then assign those permissions to users through the Users app.

What is a 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. Attributes can include:

permissionName. This represents the unique name of the permission.
displayName. This is a human-readable name for the permission that usually corresponds to the name shown in the user interface. Note that what appears in the FOLIO user interface is a translated label for the permissionName; translations are stored for supported languages with each FOLIO module. The displayName was used in earlier versions of FOLIO but no longer serves a purpose in the FOLIO user interface.
id. The id is a tenant-level unique identifier for the permission, created when the relevant FOLIO module is installed.
Description. A description of the permission as provided by the developer. This field is optional.
subPermissions. Many permissions are actually a grouping of more specific permissions - if this is the case, subPermissions is where those more specific permissions are listed.
childOf. If a permission is a subPermission for another permission, that “parent” permission is listed.
grantedTo. If the permission has been granted to any FOLIO users, their permissions user ID is listed.
mutable. A permission can be either mutable or immutable; permissions are immutable by default. If a permission is defined as “mutable” : false, then it cannot be changed without modifying the associated module code and restarting the module. If a permission is defined as “mutable” : true, it can be changed in the UI without having to stop and restart the associated module.
visible. A permission can be either visible or invisible. A permission is invisible by default. If a permission is defined as ”visible” : true, then it is viewable in the FOLIO user interface. If a permission is defined as ”visible” : false, then it is not viewable by default in the FOLIO user interface. deprecated
moduleName and moduleVersion. These fields will only appear when looking at a FOLIO installation directly, they are not in the code. These fields tell you what module provided the permission definition, and what version of that module is running.

Naming Convention

Permissions are named to indicate what a FOLIO user with the permission can do within the app.

Permission names generally follow one of two formats:

[Appname]: [What the user can do] Settings ([Area of Settings or Appname]): [What the user can do]

Examples:

Agreements: Edit agreements
- This permission allows FOLIO users to edit agreement records in the agreement app.
Settings (Inventory): Create, edit, delete material types
- This permission allows FOLIO users to access Inventory settings and add, change, or delete material types.

Key Terminology

Permission set. A permission set in FOLIO is one permission that consists of one or more subpermissions.
- Permission sets can be created in the FOLIO system by a developer.
- Permission sets can also be created by individual libraries in Settings → Users
CRUD. CRUD stands for “Create, Read, Update and Delete.” You may see it used as a shortcut terminology in permissions discussions. Most FOLIO permissions allow “CRUD” functionality - they give you the ability to create, read, update and/or delete FOLIO records.
- Note that a permission that allows for access to create, or update or delete a record will generally include the ability to view the record. For example, the permission “Users: Can edit user profile” includes a subpermission to allow viewing of user profiles. You do not need to grant a FOLIO user both permissions to allow them to view and edit user records.
Visible permission. A visible permission is one that you can see in the list of permissions in the UI. They can be assigned to patrons directly, and/or you can add them to a permission set through Settings → Users → General → Permission Sets.
Invisible Permission: An invisible permission is hidden from the FOLIO user interface, and is not usually assigned directly to a FOLIO user. Invisible permissions are commonly part of a backend module. They provide very specific, limited access to functionality in FOLIO.

Common Workflows

Common permissions workflows include:

Visible versus Invisible permissions

FOLIO permissions can be either “visible” or “invisible.”

Permissions that you see in the Users app or in Settings > Users > Permission sets are visible permissions. Developers create visible permissions by defining a group of very granular, specific permissions that when put together provide a specific function. They have a friendly display name that helps explain what the permission allows a FOLIO user to do.

Invisible permissions do not appear in the Users app by default. They are created by developers in a backend module and are not intended to be assigned directly to users. Usually, they are very granular, and control one particular action - such as the ability to view one specific type of record in an app. They have less friendly display names such as “addresstypes collection get.”

Why would I want to know about invisible permissions?

Ideally, when you’re working in FOLIO, you never have to consider invisible permissions, because the development process led to the creation of visible permissions that offer all the functionality you need.

However, occasionally bugs with permissions appear, or a feature may only be partially developed. When that happens, FOLIO administrators may need to assign an invisible permission directly to a user in order to enable a needed workflow.

How can I see invisible permissions in the FOLIO user interface?

The ability to see invisible permissions is determined user-by-user. The logged-in user must have access to Settings → Developer.

Go to Settings > Developer > Configuration.
Check the box for List ‘invisible’ permissions in add-perm menus?
Save your changes.

It is not recommended to leave this setting on permanently; there are thousands of permissions in FOLIO when including visible and invisible permissions together, and displaying invisible permissions will significantly slow down permissions management workflows.

How should I configure FOLIO to use invisible permissions with user accounts, if I need to be able to assign them to staff?

You should use permission sets.

The general approach is:

Log in as a user with appropriate permissions and turn on listing invisible permissions in FOLIO.
Go to Settings>Users> Permission sets and create a new permission set with only the invisible permissions that you need to be able to assign.
Turn off the ability to see invisible permissions.
Assign that permission set that you created to the users who need the invisible permission.

The reason to use this process rather than simply logging in as an appropriate administrator and assigning the invisible permission to staff is that other users could come in after you assign the invisible permission, edit the staff member’s account, and overwrite that administrator’s changes.

For example:

Suppose Jameca Jones, a FOLIO administrator, decides that Jeanne Dupont, a FOLIO user, needs the invisible permission “circulation-rules.storage.get” to help with troubleshooting delivery issues in FOLIO.

Jameca logs into FOLIO and enables the invisible permission option in Setting > Developer.
Jameca goes to the Users App and finds Jeanne’s record.
Jameca assigns the invisible permission to Jeanne and saves her changes.
Jameca disables the invisible permission option.

A few days later, Max Mustermann realizes that Jeanne needs the visible permission named “Courses: Read All”. Max is a manager, but not a FOLIO administrator.

Max goes into Users and looks up Jeanne’s record.
When Max views Jeanne’s account, he doesn’t see the permission “circulation-rules.storage.get” on Jeanne’s account because he doesn’t have that option turned on for his account in Settings.
Max adds the permission “Courses: Read All” and saves his changes.

When Max saves Jeanne’s record, FOLIO saves a complete new copy of Jeanne’s permissions that contains only the permissions that Max could view, which overwrites the changes that Jameca made.

In contrast, suppose Jameca uses permission sets to give Jeanne access.

Jameca goes to Settings > Developer and enables invisible permissions.
She goes to Settings > Users > Permission Sets and creates a permission set named “Troubleshooting - Circulation Rules Permissions.”
Jameca adds the invisible permission “circulation-rules.storage.get” to the permission set she has made, and saves her changes.
Jameca goes into the Users app, looks up Jeanne’s record, and assigns the permission set “Troubleshooting - Circulation Rules Permissions” to Jeanne’s account.

A few days later, Max realizes that Jeanne also needs the permission “Courses: Read All.”

Max goes to the Users app and looks up Jeanne’s record.
Max doesn’t know what “Troubleshooting - Circulation Rules Permissions” is for, but knows that administrators have been using permission sets to debug issues, so he leaves it assigned to Jeanne.
Max adds the permission “Courses: Read All” to Jeanne’s account and saves his changes.

When Max saves his changes, FOLIO saves a completely new copy of Jeanne’s permissions that still includes only the permissions Max could view. But because Max could see the permission set that Jameca created, it gets re-saved to Jeanne’s account, and she doesn’t lose the access that she needs.