Skip to end of metadata
Go to start of metadata
  • 2019 October 23: ERM update from Owen Stephens (second half of the FOLIO Forum):

              

Purpose

Agreements are a way of gathering together a wide ranging set of information to describe a library's access to a set of electronic resources. Agreements provide the facility to list electronic resources (as described in a remote, or local, knowledgebase) that the library has access to and link the resources with the relevant purchase order information, licenses (including the relevant usage/business terms), usage data providers, relevant organisations (vendors, subscription agents), library staff contacts.

Agreements integrates with many other Folio applications including:

Agreements and Knowledgebases

Agreements is intended to be used in conjunction with one or more electronic resources knowledgebase(s) which describes what electronic resources are available and how they are bundled into packages which are sold or provided by vendors and suppliers. Agreements has an internal knowledgebase which can be populated through file upload or by automatically importing data from online sources (this process is managed through the Local KB Admin application in Folio, but all the data is stored within the Agreements internal knowledgebase). Agreements also integrates with the Folio eHoldings application which allows the management of resources in a remote knowledgebase.

The fundamentals of how the Agreements application works does not change no matter which integrations are implemented. Resources are linked from the knowledgebase into an Agreement using an "Agreement Line" - which is a representation of the particular resource within an agreement. Exactly what information is displayed in the agreement may vary slightly depending on the knowledgebase integration used (as knowledgebases are not necessarily the same in terms of the metadata they store or share with the Agreements app), but the user can link from the Agreement line to the full details for a resource in the integrated knowledgebase whenever necessary.

It would be usual to choose to use either the internal knowledgebase, or to integrate with eHoldings, but it is possible to use both at the same time if that fits with a library's requirements. If a library is using only the eHoldings integration, they should hide the Agreements internal knowledgebase via the relevant setting.

Permissions

Agreements supports the following permissions:

  • Agreements: Search & view agreements
    • Allows the user to search and view agreement information
  • Agreements: Edit agreements
    • Allows the user to edit agreement records
  • Agreements: Delete agreements
    • Allows the user to delete agreement records
  • Agreements: Search & view e-resources
    • Allows the user to search and view e-resource information in the Agreements internal knowledgebase

However, because of the extensive integrations with other applications, in order to be able to use Agreements to the fullest extent a user will need permissions from a number of other applications. To fully use Agreements with all relevant integrations users will need permissions granted in the following modules:

If permissions in these applications are not granted to a user viewing or editing an agreement, that user will not be able to see the details of information from those applications.

In addition if the integration with eHoldings is being used the user will need relevant permissions granted in the eHoldings application.

Note that a user can fully access agreements and the internal agreements knowledgebase without being granted any permissions in the Local KB admin application.

UX/UI

Describe out of the box fields, including designed purpose, data requirements and validation, dependencies between fields. 
Describe out of the box accordion menus, including purpose of the menus, customization options, and associated permission controls (if any)
Describe any workflows available through navigation menus, including purpose of the workflow, customization options, and associated permission controls.

Searching

Describe pathways for searching in the app/feature through the UI.
Describe fields that are indexed in the back end specifically for searching
Describe any advanced searching features and how they would work.

Functional workflows

Describe available tasks that can be conducted in the app. To document those tasks, create a new page and link it to this page.
Describe action-based permissions that are connected to these functional workflows, if any.

Reporting

Describe available in-app reports, including parameters for the reports, and associated permissions.
If there are developed LDP reports/queries for this app / area of FOLIO, describe those reports as well.
List any fields that may not be available in the LDP (e.g., for privacy reasons.)

Integrations

Describe any APIs that interact with the app. Provide links to the API / module information in Github.
Describe integrations that individual libraries may wish to develop for this app / area of FOLIO, if relevant.
If existing integrations have been developed by adopting libraries, provide links to the integration in Github or wherever the information can be found.

Describe and include any permanent links such as a link structure to records, searches, etc

Considerations for Implementation

Describe decisions or implications that need to be considered when implementing this feature.

Include topics such as order of operations during implementation or affects of implementing in a certain way.

  • No labels