Field metadata constraints
Fields metadata constraints framework defines a metadata-driven system to enforce field-level and cross-field validation rules, that is, one-way dependencies where field B values are constrained by field A. It provides a flexible, scalable metadata system to standardize constraint management, improve data integrity, and enable dynamic form behavior across the Beeline Professional platform.
The framework is designed to be extensible. Available data sets are exposed in the Create New Field Constraint window based on the selected resource type. The framework will be expanded incrementally to support additional use cases based on client requirements.
Key capabilities
Fields metadata constraints framework enables dynamic configuration of constraints, using a 2D model where columns represent constraining values and rows define allowed values. It supports backend-enforced consistency across UI, APIs, and document services, with tenant-level configuration applied per entity.
User experience
The framework provides a metadata UI for table-based configuration and editing, allowing users to define constraint relationships directly in Professional. It also supports spreadsheet import and export for managing large datasets and enables dynamic filtering of dropdown fields within forms based on selected values.
Constraint behavior
Although constraints are defined as one-way, for example, cost center constrained by business site, the selection behavior is effectively bidirectional. Selecting a value in either field implicitly restricts the available values in the related field.
When both fields are mandatory and configured across separate smart forms, this can lead to locked selections after save. Subsequent forms will continue to filter options based on previously selected values, preventing users from resetting or changing the relationship.
| To prevent locked states, avoid configuring mutually constraining fields as mandatory when they are placed on separate smart forms. |
Additionally, constraint enforcement is inclusive rather than exhaustive. If a value, for example, a cost center, is not defined in the constraint matrix, it remains available for selection regardless of the constraining field value, and in this example, regardless of a business site.