Settings - Tenant - Location Setup - Campus

Information in italics is intended to provide guidance while writing documentation and in general should be removed when a doc is at a v.1 stage.
The italics are suggestions to help guide what might go in a particular section. If you feel a section does not apply to the app or feature, please keep the section but just add that it does not apply.
If you feel it makes more sense for your documentation, you can move sections up and down.

Purpose

Campus is the second level of the Location hierarchy.

FOLIO libraries will need at least one institution, and one campus, to create elements further down the location hierarchy - library and location.

The four pieces of the location hierarchy are available criteria to use in circulation rules.

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.

Libraries may think of campus geographically, or through other frameworks - there is no requirement in FOLIO that Campus be a geographic location. 

An example of how you might think of using campus other than strictly geography:

  • Medium University has one location in Big City.
    • They have a central library system that has six branches and is managed centrally.
    • They also have two other libraries, attached to professional school programs, that are managed by those professional schools. 

If you think about this scenario geographically, you might represent it as

  • One Institution - Medium University
  • One Campus - Big City
  • Eight Libraries ....

and so on.

But, you could also think about it from a management framework, like this:

  • One Institution - Medium University
  • Two Campuses - Big City-Central and Big City-Professional
  • Either Libraries....

and so on.

The advantage of the management framework is that if the six libraries that belong to Big City-Central have policies that are the same, you can write the policy at the campus level of the hierarchy instead of the library level of the hierarchy. So for the policies that are the same, you only have to write one circulation rule, instead of six.

Permissions

There is one permission control currently implemented for this area of Settings:

  • Settings (tenant): Can create, edit and remove locations

There are no action-based permissions currently implemented for this area of Settings. If that changes, please update this information.

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.

  • The Campus Name must be unique within the tenant at its level of the hierarchy. EG, you can't have two campuses with the same name.
  • The Campus Code must also be unique within the tenant at its level of the hierarchy. Note that as of Q12020 you can currently save two campuses with the same code. See  CIRCSTORE-143 - Getting issue details... STATUS  for information about the status of this bug.

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.

There is no default search function in the GUI for Campus records. 

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.

  • Creating, Editing, Deleting Campuses

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