Overview recordings and links
- 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:
- Dashboard
- eHoldings
- ERM Comparisons
- eUsage
- Licenses
- Local KB Admin
- Notes
- Orders
- Organizations (including Interfaces)
- Users App
- Tags
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
Agreement fields
Agreement field documentation is available in the linked Google sheet.
Calculated fields/data
Some aspects of an agreement are calculated based on data that has been entered/linked to the agreement. These are:
| Displayed information | Rules for calculating |
|---|---|
| Period start and Period end dates in the Agreement view | If there is a current period defined for the agreement (a period that has a Start date in the past and an End date in the future (or no End date specified), the "Period start" and "Period end" dates in the Agreement view will reflect the current period start and end. If the Agreement does not have a current period, then the Period start and Period end will reflect the earliest start date (out of all the agreement periods) and the latest end date (also out of all the agreement periods). This is so that for historical agreements you always see the full time that agreement ran for. |
| License and Business Terms | The license and business terms for an agreement are calculated based on the "Controlling License" (a linked license with the status of "Controlling") and any Current Amendments (Amendments on the Controlling License that have been given the Status (this agreement) of "Current" The terms of any current amendment will add to and (where necessary) override the terms stated in the underlying license. For a controlling license with a single current amendment:
Where there are multiple “current” amendments, the terms from the amend will be applied in order of the amendment start date. So in the case of licenses or amendments having different values for the same term, the value from the amendment with the most recent start date will be used as the correct value for that term in the agreement. |
E-resources covered by this agreement: Current / Future / Dropped / All | This field is only relevant and calculated when the agreement contains agreement lines based on resources in the Agreements internal knowledgebase. ... (work in progress!)... |
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.