Hi Team Volaris,

Context & Community Status: This inquiry is part of an internal pre-analysis at SLUB Dresden. This concept has not yet been presented to the broader FOLIO community or the respective SIGs. Before we bring this proposal forward for community discussion, we want to clarify the underlying technical feasibility with you.

Because we need to implement a high number of custom fields, we must structure them visually for our users. The idea is to dynamically assign fields to separate UI accordions (Sections) instead of rigidly rendering all custom fields inside the single default "Custom fields" accordion.

Our Core Questions for You:

👉 Can the mod-custom-fields schema be extended so that field definitions can be mapped to a dynamically managed section_id?
Is the existing accordion configuration logic (such as displayInAccordion / accordion) in the backend and within stripes-smart-components flexible enough to handle separate target accordions per record type within the same app module (e.g., separate layout configurations for PO vs. POL)?

🔗 For more information, see:

Visualization of our Goal:

Fig. A: Manage (i.e., create, rename, delete) accordion sections of custom fields in the Settings app.

(Explanation for Volaris: A new sub-menu/endpoint would manage layout sections as a controlled vocabulary, giving each custom accordion a unique ID).

Fig. B: Assign previously defined sections to each custom field in the Settings App.

(Explanation for Volaris: Within the custom field definition, the schema would need to store the assigned section_id via a simple dropdown selection).

Fig. C: View custom fields within structured accordion sections in the Orders app.

(Explanation for Volaris: The custom fields module should group and render fields into visually separate, collapsible accordions based on their assigned section_id rather than displaying them in one single block).

Custom Fields Functional Extension

Overview

This ticket outlines extensions for the custom-fields module to support flexible capture of institution specific data (e.g., provenance research, preservation) directly within core apps like Inventory and Orders.

We are currently in the initial analysis and development phase. Before proceeding further, we are seeking a preliminary feasibility assessment to determine if the proposed directions are viable within the FOLIO ecosystem.

New Field Types

We propose the introduction of two fundamental new field types to enhance data integrity and reduce manual entry:

Look-up Fields: Integration of standard FOLIO plugins (Smart Components) to link records from other apps (Organizations, …) directly.

Fig.: Add a new Lookup custom field in the Settings app.

Fig.: Edit Lookup custom field properties in the Settings app.

Fig.: Lookup custom field in the Orders app (Edit mode).

Fig.: Select Organizations dialog box opened after Organizations look-up link was clicked (Edit mode).

Fig.: Lookup custom field in the Orders app (View mode).

API-Endpoint Fields: A new type, SETTINGS_SINGLE_SELECT_DROPDOWN, which dynamically fetches values from controlled vocabularies in the Settings app (e.g., acquisition-methods).

Fig.: Add a new API endpoint custom field in the Settings app.

Fig.: Edit API endpoint custom field properties in the Settings app.

Fig.: API endpoint custom field in the Orders app (Edit mode).

Fig.: API endpoint custom field in the Orders app (View mode).

Main reason is the implementation of acquisition information in items without orders. Dennis Bridges recommended to apply custom fields instead of implementing a new accordion with new specific fields.

See: https://folio-org.atlassian.net/wiki/spaces/~7120204b85766de9d0443f82ea93bb3958da08/pages/1022033962

Structure & Layout

In SLUB, we would create many customs fields. To improve the usability, we would implement options to structure the fields by specific subject areas (acquisitions, serials, provenance research, …)

Option 1: Grouping by multiple new Accordions: Enhancing the displayInAccordion functionality to allow the creation of custom UI sections without requiring code changes to the respective module.
- We would implement the opportunity to create institution-specific accordions.

Fig.: Manage (i. e. create, rename, delete) accordion sections of custom fields in the Settings app.

Fig.: Apply created accordion sections to custom fields in the Settings app.

Fig.: View custom fields within structured accordion sections in the Orders app.

Option 2: Separators: Introduction of visual dividers to improve the scannability of large forms.
- If option 1 is not possible, we would try to apply separators (lines, …) to structure the custom fields.

Fig.: Add a new Separator custom field in the Settings app.

Fig.: Two Separator custom fields added between other custom fields in the Settings app.

Fig.: View custom fields structured by Separators in the Orders app.

Scope of Implementation

1. Plugin & Settings Integration

UUID Storage: Look-ups will primarily store the UUID of the target record. This ensures that if a vendor name is changed in the Organizations app, the reference in the custom field remains accurate.
Dynamic API Configuration: Administrators can define the specific API endpoint path in the settings to populate dropdown menus dynamically.

2. UI/UX Enhancements

Edit/View Modes: Ensuring linked look-ups render as clickable links in View Mode, taking the user directly to the related record.
Configurable Headers: Development of a Settings interface to define new accordion labels, which will then appear in the Custom Field configuration dropdown.
New accordions: Implementation of the opportunity to create institution-specific accordions. Here, we want to ask explicitly if this is possible.

Request for Feedback & Next Steps

Feedback Request 1 (Performance): Is the performance impact of multiple API calls (to resolve UUIDs into display labels in List Views) acceptable, or should we implement a "snapshot" approach (storing both UUID and Label)?
Feedback Request 2 (Permissions): Should access to look-up data (e.g., viewing user names in a custom field) be governed by the custom field's permissions or the user's existing permissions for the target app?
Next Steps:
1. Develop technical Proof of Concepts (POCs) for FieldArray integration in the frontend.
2. Coordinate with the FOLIO Product Council regarding proposed backend schema changes.
3. Finalize mockups for the configuration UI of the new field types.
4. Creation of Jira-Tickets

Using Accordions to Structure Custom Fields into Dynamic Sections