Custom Fields

FullFabric uses the Schemable system to let institutions define custom data fields on profiles, applications, forms, and other entities — without code changes. Schemas define the structure, field types, visibility rules, and completion tracking for dynamic data.

Overview

A schema is a container of sections, each containing fields. Fields can be text inputs, dropdowns, file uploads, matrices, and more. The system supports conditional visibility, field-level permissions, localization, and completion tracking.

flowchart TD
    S[Schema] --> Sec1[Section: Personal Info]
    S --> Sec2[Section: Education]
    Sec1 --> F1[Field: First Name]
    Sec1 --> F2[Field: Country]
    Sec1 --> F3["Field: US State
(visible if Country = US)"]
    Sec2 --> F4[Field: Degree]
    Sec2 --> F5[Field: Transcript Upload]

Schemas

A schema is the top-level container. Institutions define schemas for profiles, applications, evaluations, forms, and other entities. Schemas can be duplicated to create copies with all sections, fields, and option sets.

Sections

Sections group fields into logical units (e.g., "Personal Information", "Education Background"). Each section has a localized label and description, an ordered list of fields, and optional conditional visibility rules.

Sections support the same conditional visibility rules as fields — an entire section can be shown or hidden based on the value of another field.

Field Types

The Schemable system provides 25 field types:

Text & Numbers

Type	Description	Configuration
SingleLineText	Short text input	`char_length` for max characters
ParagraphText	Multi-line text area	`word_limit` for max words
Number	Numeric input	`allow_decimal` for float values
Instructions	Non-interactive display text	Read-only content shown to users

Dates

Type	Description	Configuration
Date	Date picker	`date_range_validation`, `date_min`, `date_max`
DateTime	Date and time picker	Same as Date
MonthYear	Month and year only	Stored as hash

Selection

Type	Description	Configuration
DropDown	Single or multi-select from options	Uses option set or inline options
CheckBox	Multiple checkbox selection	Uses option set or inline options
CascadingDropDown	Parent-child linked dropdowns	Hierarchical option structure
Country	Country selector	Auto-linked to Countries option set

Contact & Identity

Type	Description	Configuration
Email	Email with validation	Standard email validation
SmartEmail	Email with bounce/verification tracking	Bounce, spam, and verification status
Address	Multi-part address form	Subfields: line_1, line_2, line_3, city, state, post_code, country

Files & Media

Type	Description	Configuration
File	File upload (single or multi)	`accepted_file_extensions`, `multiple_files`
Video	Video embed or link	URL-based

Structured Data

Type	Description	Configuration
Matrix	Table grid with rows and columns	`matrix_options` with rows, columns, and weights
ExtendableMatrix	Matrix with dynamic row addition	Same as Matrix, plus user-added rows
Rows	Simple rows container	Array storage

References

Type	Description	Configuration
Organisation	Link to an Organization record	Organization lookup
Programme	Programme/course reference	Programme selection
Referee	Reference contact	Contact details
SequentialId	Auto-generated ID	`prefix` for ID format (e.g., "APP-001")

Option Sets

Option sets are reusable lists of values shared across fields and schemas. Each option set contains ordered values with localized translations and integration mappings.

flowchart LR
    OS[Option Set: Nationalities] --> V1["Value: British
HubSpot: british
DE: Britisch"]
    OS --> V2["Value: French
HubSpot: french
DE: Französisch"]
    OS --> V3["Value: German
HubSpot: german
DE: Deutsch"]

Value Properties

Each option value has:

Order — Position in the list
Translations — Localized display names (e.g., "British" in English, "Britisch" in German)
Integration mappings — External system values (e.g., HubSpot value, Salesforce value)

System Option Sets

Some option sets are built-in — like Countries — and are automatically linked to their corresponding field types.

Propagation

When an option set is updated, changes are automatically propagated to all fields using it.

Conditional Visibility Rules

Fields and sections can have rules that control their visibility and required status based on the values of other fields. This enables dynamic forms that adapt to user input.

Rule Types

Rule	Description	Example
Is	Value equals	Show "US State" if Country is "US"
IsNot	Value does not equal	Show "Other" field if Country is not in list
Contains	Value contains substring	Show field if notes contain "scholarship"
DoesNotContain	Value does not contain	Hide if description doesn't contain keyword
IsEmpty	Value is blank	Show prompt if field is empty
IsNotEmpty	Value has content	Show dependent field only when parent is filled
IsGreaterThan	Numeric comparison	Show section if score > 50
IsLessThan	Numeric comparison	Show warning if GPA < 2.0
IsGreaterThanOrEqualTo	Numeric >=	Require field if age >= 18
IsLessThanOrEqualTo	Numeric <=	Hide if years <= 0
Always	Always satisfied	Default visibility
Never	Never satisfied	Permanently hidden

Rule Applications

Rules are applied in three contexts:

Context	Property	Effect
Visibility	`is_visible_rules`	Controls whether the field is shown
Required	`is_required_rules`	Controls whether the field must be filled
Availability	`is_available_rules`	Controls whether the field is available for certain roles

Rules support nested field access — a rule can reference a field on a related object (e.g., organization.country).

Dependent Fields

When a field has visibility rules that reference another field, it becomes a dependent field. The system tracks these dependencies so that when a controlling field's value changes, dependent fields can be re-evaluated and cleared if they become invisible.

Completion Tracking

Schemas calculate completion percentage for a document — how many of the visible fields have been filled in.

Option	Description
`require: :all`	All visible fields must be complete (default)
`require: :required`	Only required fields count toward completion
`ignore: [types]`	Skip specific field types (e.g., File uploads)

The completion calculation:

Collects all fields that are visible? for the document
Filters by required-only if specified
Excludes ignored field types
Validates each field using type-specific validators
Returns completed_count / total_count * 100

Field Configuration

Permission Controls

Every field has role-based visibility and editability. You can control which roles can see and which roles can edit each field. Values can be "anyone", a role state (e.g., "admin"), or a specific role (e.g., "staff::admissions"). See Schema Permissions for details.

Display Controls

Fields also support these display options:

Setting	Description
Visible by default	Whether the field is shown
Unique	Whether the value must be unique across all profiles
Role-specific	Show only for profiles with specific roles
Campus-specific	Limit display to specific campuses
Bulk update	Whether the field can be updated in bulk operations

Localization

Both sections and option set values support multiple locales. Each section has a locals collection with label and description per locale (e.g., "en-GB", "de-DE", "pt-BR"). The first locale is treated as the default.

Lifecycle & Journeys

Segments