Purpose:
Permission sets in FOLIO are built to allow local user administrators to quickly authorize users to perform functions in FOLIO. This document describes policies for creating new permission sets and managing existing permission sets
Scope:
The creation of new permission sets and continued maintenance of existing permission sets
Description:
Permission Sets were initially built based on workflows used by 5C Libraries and minimum permissions that would allow a user to perform a function without an error. They were intended to be flexible enough that 5C members could assemble combinations of permissions for their users while still allowing the sets to be centrally administered.
In FOLIO, all actions users can perform are governed by Permissions. Every action a user can perform must be explicitly enabled. FOLIO developers create two kinds of permissions:
Visible, immutable permissions (Permissions): These can be assigned to users to allow them to perform one or more types of action in FOLIO. These sets cannot be altered through the user interface.
Invisible permissions: Invisible permissions are more granular than visible permissions. They cannot be assigned to users and are not visible through the user interface. A visible, immutable permission consists of one or more invisible, immutable permissions.
A FOLIO administrator creates Permission sets. A permission set consists of one or more Visible, immutable permissions or other Permission sets. A permission set is Visible and Mutable.
Permission Sets are assigned to FOLIO users to allow them to work in FOLIO
FOLIO Domain is an informal group of related modules in FOLIO. When multiple modules are used as part of a single workflow OR a module requires another module to function, they are considered a domain. Examples would include Organizations, Orders, Invoices and Receiving, as Orders domain; or Orders, Agreements, eHoldings and Organizations, as E-resource management domain .
Creation and maintenance of Permission Sets
As FOLIO continues to evolve, it will be necessary to add or remove permissions from permission sets. This is necessary either to grant users access to additional functionality as new features are added, or to maintain existing functionality as application permissions change.
Permission sets have been designed to allow users to perform all steps of workflows in a FOLIO Domain with a single set.
Example: an agreement workflow requires creating and assigning an organization, therefore the permission set should include both create agreements and create organizations
If a module will raise an error if a user tries to perform a function because permission for another module is required, then that permission should be included in the set
A set should always include the minimum permissions required to do the task
Example: If a workflow requires create/edit/view an order, and view a User, the permission set should only grant the ability to view a user (the minimum permission) but to create/edit/view an order (a high level permission)
Permission sets are designed to have degrees of permission to allow higher level tasks to be performed
Each higher level permission set should include the lower level permission set for ease of management
Invisible permissions should never be mixed with permissions in a set
Add-On sets
In some cases it may be preferable to grant permission sets that do not meet the above criteria. These “Add-On Sets” are only valid with the use of other sets.
The domain is very large.
The number of users is small
The most common use case for this is Data import. Data import requires a large number of permissions to function, in addition to permissions required to access the app. It is used by a small number of users.
Invisible sets
Invisible permissions should only be created under special circumstances, the most common of which is when a permission does not include all the needed invisible, immutable permissions. Because there may be errors that occur if a permission and invisible permission are included on the same set, invisible permissions should be grouped into a permission set, and that set should be assigned as necessary.
Integration Users
Third party FOLIO integrations typically require a FOLIO user to perform their functions. This user requires permissions like any other user. A FOLIO integration can perform any function a user can perform, but lacks the restrictions of working in a user interface, and may circumvent business logic. Integrations are designed for one purpose and will not need the full range of permissions that a user has in the FOLIO User Interface.
Integration Users should only be given the permissions needed to function. They should not be given permission sets.
In extreme cases where integration requires a permission that grants overly broad access, a more limited invisible permission may be considered.
See Integration users for more information