For shortText, SolidX validates in two places:

1. The generated form layer validates required, min, max, and regexPattern.
2. The backend validation layer checks requiredness, string type, maximum length, and regex compliance.

Two important behaviors to note:

• max is the effective length limit enforced by backend validation
• min is enforced in generated form validation

shortText is persisted as a scalar string field.

The submitted value is validated and then stored without field-specific transformation.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because shortText is a scalar textual field, it works naturally with the standard text-oriented filter operators available in SolidX, including:

• equality and inequality
• in and notIn
• contains and notContains
• case-insensitive contains variants
• startsWith and endsWith
• null and not-null checks

This makes shortText a natural fit for searchable list views, user keys, codes, names, and other text-oriented query flows.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "bankUserId",
  "displayName": "Bank User ID",
  "description": "Bank UserId (MER followed by customer CIF)",
  "type": "shortText",
  "ormType": "varchar",
  "defaultValue": null,
  "required": true,
  "min": 9,
  "max": 16,
  "regexPattern": null,
  "regexPatternNotMatchingErrorMsg": null,
  "unique": false,
  "index": true,
  "columnName": null,
  "private": false,
  "isUserKey": false,
  "enableAuditTracking": true,
  "isSystem": false,
  "isMarkedForRemoval": false,
  "isPrimaryKey": false
}

This is a representative shortText field because it combines a clear business purpose with required validation, explicit length limits, and index intent.

For longText, SolidX validates in two places:

1. The generated form layer validates required, min, max, and regexPattern.
2. The backend validation layer checks requiredness, string type, and regex compliance.

Two important behaviors to note:

• min and max are enforced in generated form validation
• backend validation does not currently enforce min or max for longText

longText is persisted as a scalar text field.

The submitted value is validated and then stored without field-specific transformation.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because longText is a scalar textual field, it works naturally with the standard text-oriented filter operators available in SolidX, including:

• equality and inequality
• in and notIn
• contains and notContains
• case-insensitive contains variants
• startsWith and endsWith
• null and not-null checks

This makes longText suitable for description-style filters, notes, instructions, and text-driven administrative search flows.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "description",
  "displayName": "Description",
  "description": null,
  "type": "longText",
  "ormType": "text",
  "isSystem": false,
  "regexPattern": "",
  "regexPatternNotMatchingErrorMsg": "Invalid regex pattern",
  "defaultValue": null,
  "min": null,
  "max": null,
  "required": true,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "enableAuditTracking": false
}

This is a representative longText field because it shows the usual multiline text contract: semantic text storage, optional regex support, and standard required handling.

For richText, SolidX validates in two places:

1. The generated form layer validates required, min, max, and regexPattern.
2. The backend validation layer checks requiredness, string type, and regex compliance.

Two important behaviors to note:

• min and max are enforced in generated form validation
• backend validation does not currently enforce min or max for richText

richText is persisted as a scalar text field.

The submitted value is validated and then stored without field-specific transformation.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because richText is a scalar textual field, it works naturally with the standard text-oriented filter operators available in SolidX, including:

• equality and inequality
• in and notIn
• contains and notContains
• case-insensitive contains variants
• startsWith and endsWith
• null and not-null checks

This makes richText suitable for administrative search and text-driven query flows, even though end-user presentation is usually richer than plain text.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "content",
  "displayName": "Content",
  "description": null,
  "type": "richText",
  "ormType": "text",
  "isSystem": false,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null
}

This is a representative richText field because it captures the typical contract: formatted content stored as text and rendered through the rich-text form experience.

For json, SolidX validates in two places:

1. The generated form layer checks requiredness.
2. The backend validation layer checks requiredness and validates that the submitted value is valid JSON.

One important behavior to note:

• unlike text-based field types, the backend validator explicitly checks whether the submitted value is valid JSON rather than only checking its scalar type

json is persisted as structured JSON data according to the configured ormType.

The submitted value is validated and then stored without field-specific transformation in the CRUD manager itself.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

json is structurally different from scalar text and numeric fields.

At the field-contract level, it can participate in standard persistence and retrieval flows, but JSON-aware filtering behavior depends heavily on the storage model and the query path being used. For this reason, JSON fields should be treated more conservatively than ordinary scalar fields when designing search and list experiences.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "metadata",
  "displayName": "Metadata",
  "type": "json",
  "ormType": "simple-json",
  "required": false,
  "unique": false,
  "index": false,
  "private": false
}

This is a representative json field because it shows the core contract clearly: structured data storage, JSON-specific validation, and a persistence-oriented ormType.

For int, SolidX validates in two places:

1. The generated form layer validates requiredness and numeric bounds using a number-aware schema.
2. The backend validation layer checks requiredness, integer shape, and numeric bounds.

Three important behaviors to note:

• int expects whole-number values rather than decimal values
• min and max represent numeric bounds, not string length
• int does not use text-oriented attrs such as length or regexPattern

int is persisted as a scalar integer-style value.

The submitted value is validated and then stored without field-specific transformation in the CRUD manager itself.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because int represents a numeric scalar, it works naturally with numeric sorting, exact-match filtering, and bounded comparisons.

Typical use cases include:

• sorting records by sequence or rank
• filtering by counts and operational thresholds
• reporting on durations, quantities, or other whole-number metrics

In practice, int is the natural choice when business meaning depends on numeric ordering rather than on text search.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "totalCopies",
  "displayName": "Total Copies",
  "description": null,
  "type": "int",
  "ormType": "integer",
  "defaultValue": null,
  "min": 1,
  "max": null,
  "required": true,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "enableAuditTracking": true,
  "isPrimaryKey": false
}

This is a representative int field because it shows the common contract clearly: a persisted whole-number value, a numeric minimum bound, and a business rule where fractional precision would not make sense.

For bigint, SolidX validates requiredness and numeric shape at the CRUD boundary, and generated forms reuse the same whole-number editing experience used for int.

Two important behaviors to note:

• backend validation accepts string or number inputs and coerces them into a bigint-aware value before applying the numeric checks
• the generated UI currently reuses the integer field path, so very large values should be reviewed carefully when they may exceed JavaScript safe-integer handling

bigint is intended to persist a large whole-number value.

The submitted value is validated and then stored without field-specific transformation in the CRUD manager itself.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because bigint remains a numeric scalar, it fits the same broad query patterns as int.

Typical use cases include:

• sorting by imported numeric identifiers
• exact lookup by large request or transaction keys
• operational reporting on large-duration counters and legacy numeric values

In practice, bigint is most useful where whole-number semantics matter but ordinary integer assumptions are too small or too implementation-specific.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "timeRequestInMillisecond",
  "displayName": "Time Request In Millisecond",
  "description": null,
  "type": "bigint",
  "ormType": "bigint",
  "defaultValue": null,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": "TimeReqInMillsec",
  "enableAuditTracking": true,
  "isPrimaryKey": false
}

This is a representative bigint field because it shows the intended contract clearly: a persisted large whole-number value, a bigint-specific storage hint, and a business metric that should remain numeric rather than textual.

For decimal, SolidX validates in two places:

1. The generated form layer validates requiredness and numeric bounds using a number-aware schema.
2. The backend validation layer checks requiredness, numeric shape, and numeric bounds.

Three important behaviors to note:

• decimal accepts numeric values with fractional precision
• min and max represent numeric bounds, not string length
• decimal does not use text-oriented attrs such as length or regexPattern

decimal is persisted as a scalar precision-aware numeric value.

The submitted value is validated and then stored without field-specific transformation in the CRUD manager itself.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because decimal represents a numeric scalar, it works naturally with sorting, exact-match filtering, and bounded comparisons.

Typical use cases include:

• filtering records by amount thresholds
• sorting balances, prices, or rates
• reporting on numeric values where fractional precision matters

In practice, decimal is the natural choice whenever business meaning depends on numeric precision rather than on textual formatting.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "latePaymentFees",
  "displayName": "Late Payment Fees",
  "description": null,
  "type": "decimal",
  "ormType": "decimal",
  "defaultValue": "0",
  "min": null,
  "max": null,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "enableAuditTracking": true
}

This is a representative decimal field because it shows the common contract clearly: a persisted precision-aware numeric value, a decimal-oriented storage hint, and a default that fits amount-style workflows.

For boolean, SolidX validates in two places:

1. The generated form layer validates requiredness using a boolean-aware schema.
2. The backend validation layer checks requiredness and boolean type.

Two important behaviors to note:

• boolean does not use text-oriented attrs such as min, max, length, or regexPattern
• at the CRUD boundary, the runtime value is treated as a true-or-false field rather than as free-form text

boolean is persisted as a scalar boolean field.

The submitted value is validated and then stored without any field-specific persistence transformation.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because boolean represents a binary state, it is most useful in exact-match style filtering and operational list views.

Typical use cases include:

• filtering records by enabled versus disabled state
• separating approved and unapproved records
• narrowing operational queues by simple flags such as duplicate, active, verified, or system-owned

In practice, boolean fits best where users need to quickly slice a dataset by state rather than search inside a textual value.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "isPBLEnabled",
  "displayName": "PBL",
  "description": null,
  "type": "boolean",
  "ormType": "boolean",
  "defaultValue": "true",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "enableAuditTracking": true,
  "isSystem": false
}

This is a representative boolean field because it captures the common contract clearly: a persisted state flag, an explicit storage intent, and a default value used by metadata-driven experiences.

For date, SolidX validates in two places:

1. The generated form layer validates requiredness using a date-aware schema.
2. The backend validation layer checks requiredness and date type.

Two important behaviors to note:

• date does not use text-oriented attrs such as min, max, length, or regexPattern
• the same CRUD validation path is also reused for datetime, so date-like fields share a common backend date-validation contract

date is persisted as a scalar date value.

The submitted value is validated and then stored without any field-specific persistence transformation in the CRUD manager itself.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because date represents a calendar value, it is well suited to time-oriented filtering and reporting.

Typical use cases include:

• sorting records by chronology
• filtering records by a specific day
• narrowing datasets by effective date, approval date, or joining date

In practice, date works best where users need consistent calendar semantics rather than free-form text search.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "doj",
  "displayName": "DOJ",
  "description": "date of joining",
  "type": "date",
  "ormType": "date",
  "defaultValue": null,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "enableAuditTracking": true,
  "isSystem": false
}

This is a representative date field because it captures the typical contract clearly: a persisted calendar value, a date-specific storage intent, and a business use case that benefits from consistent date handling.

For datetime, SolidX validates in two places:

1. The generated form layer validates requiredness using a date-aware schema.
2. The backend validation layer checks requiredness and date type through the shared date-time validation path.

Two important behaviors to note:

• datetime does not use text-oriented attrs such as min, max, length, or regexPattern
• the same CRUD validation path is currently shared with date, so both field types rely on the same backend date-validation contract

datetime is persisted as a scalar timestamp-like value.

The submitted value is validated and then stored without any field-specific persistence transformation in the CRUD manager itself.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because datetime represents a timestamp-like value, it is well suited to chronological reporting and operational history flows.

Typical use cases include:

• ordering records by event time
• filtering by publication, approval, or execution time
• presenting audit-style timelines and process timestamps

In practice, datetime is the natural choice whenever time-of-day matters as much as the date itself.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "startTime",
  "displayName": "Start Time",
  "description": null,
  "type": "datetime",
  "ormType": "datetime",
  "defaultValue": null,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": "StartTime",
  "enableAuditTracking": true,
  "isSystem": false
}

This is a representative datetime field because it captures the common contract clearly: a persisted timestamp, a timestamp-oriented storage intent, and a business use case that benefits from time-aware presentation and sorting.

For time, SolidX currently validates requiredness in the generated form layer using a date-like schema.

One important behavior to note:

• core UI support for time is present, but crud.service.ts does not currently route SolidFieldType.time through a dedicated backend field manager, so the backend runtime contract is not yet as complete as the contracts for date and datetime

time is intended to persist a clock-time value.

At the UI layer, the selected time is normalized into a submitted value during form-data generation. At the backend layer, the field contract is present, but the dedicated CRUD-manager path is not currently wired in the same way as other mature scalar field types.

Attrs such as ormType, columnName, unique, and index should therefore be understood as persistence and schema intent, with the current implementation maturity taken into account.

Because time represents a clock-time value, it is most useful for schedule-style displays and ordering within a business day.

Typical use cases include:

• start and end times for scheduled jobs
• opening and closing times
• time-only display in generated forms and reports

In practice, time is best used where the UI experience is valuable today and the backend behavior is known and reviewed as part of implementation.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "startTime",
  "displayName": "Start Time",
  "description": null,
  "type": "time",
  "ormType": "time",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "isSystem": false
}

This is a representative time field because it shows the intended contract clearly: a clock-time value with a dedicated UI experience and a time-specific storage intent.

For email, SolidX validates in two places:

1. The generated form layer validates requiredness, min, max, and regexPattern.
2. The backend validation layer checks requiredness, email shape, maximum length, and regex compliance.

Three important behaviors to note:

• backend validation uses an email-aware validator even when no custom regex is authored
• generated form validation relies on regexPattern when stricter email-format checks are needed
• max defaults to the email-safe core limit when it is not authored explicitly

email is persisted as a scalar text field.

The submitted value is validated and then stored without any field-specific persistence transformation.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because email is a scalar textual field, it works naturally with the standard text-oriented filter operators available in SolidX.

Typical use cases include:

• exact lookup by email address
• partial search in operational lists
• identifying records by a stable contact identifier

In practice, email combines the searchability of text with stronger validation expectations than a generic short string.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "payByLinkCustomerEmailAddress",
  "displayName": "Pay By Link Customer Email Address",
  "description": null,
  "type": "email",
  "ormType": "varchar",
  "regexPattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$",
  "regexPatternNotMatchingErrorMsg": "Invalid regex pattern",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "enableAuditTracking": false,
  "isSystem": false
}

This is a representative email field because it shows the email-specific validation intent clearly while still behaving like a persisted scalar string field.

For password, SolidX validates in two places:

1. The generated form layer validates requiredness, min, max, regex compliance, and password-confirmation matching.
2. The backend validation layer checks string type, password-strength regex compliance, min, max, and password-confirmation matching.

Three important behaviors to note:

• backend requiredness is applied on create rather than on ordinary update flows
• password confirmation is treated as part of the contract when a password value is supplied
• when no custom regex is authored, the backend falls back to a strong-password default pattern

password is not intended to persist as raw text.

When a password value is supplied, the password manager hashes it before persistence and also records the active password scheme and hash version metadata used by the hashing service.

Attrs such as ormType, columnName, unique, and index should therefore be understood carefully in the context of hashed secret storage rather than ordinary text persistence.

password is not intended for ordinary filtering, search, or list presentation.

In practice, password fields are authored and updated through controlled form flows rather than surfaced in searchable operational views.

Attrs such as private, enableAuditTracking, and isSystem matter more here than for most scalar field types because the field carries secret-like data. Documentation and implementation should continue to treat password values as highly sensitive.

{
  "name": "password",
  "displayName": "Password",
  "type": "password",
  "ormType": "varchar",
  "length": 512,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "isSystem": true
}

This is a representative password field because it captures the typical secret-field contract clearly: string input, secure validation expectations, and persistence sized for hashed storage rather than raw display.

For selectionStatic, SolidX validates in two places:

1. The generated form layer validates requiredness and the expected selection shape.
2. The backend validation layer checks requiredness, stored value type, and whether the submitted value belongs to the authored option set.

Three important behaviors to note:

• selectionStaticValues defines the allowed set using value:label entries, where the left-hand side is the stored value and the right-hand side is the display label
• selectionValueType controls how the submitted value is interpreted at validation time
• when isMultiSelect is enabled, the backend accepts an array or a JSON-stringified array and validates each submitted value against the authored set

selectionStatic persists the stored value token rather than the human-readable label.

For single-select fields, that typically means a scalar value such as Draft or active. For multi-select fields, the value is treated as a collection of authored stored values.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because selectionStatic stores a constrained set of known values, it is well suited to operational filtering and reporting.

Typical use cases include:

• filtering by status, stage, type, or category
• segmenting records by workflow state
• narrowing records by authored option sets such as day of week, product type, or review outcome

In practice, selectionStatic is most valuable where consistency matters more than free-form input.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "status",
  "displayName": "Status",
  "description": "Status of the application",
  "type": "selectionStatic",
  "ormType": "varchar",
  "defaultValue": "Draft",
  "selectionStaticValues": [
    "Draft:Draft",
    "With Checker:With Checker",
    "Approved:Approved",
    "Rejected:Rejected",
    "Discrepancy:Discrepancy"
  ],
  "selectionValueType": "string",
  "isMultiSelect": false,
  "required": false,
  "unique": false,
  "index": true,
  "private": false,
  "columnName": null,
  "enableAuditTracking": true,
  "isSystem": false
}

This is a representative selectionStatic field because it shows the authored option set, the stored-value contract, and a common status-style use case that benefits from indexing and consistent querying.

For selectionDynamic, SolidX validates in two places:

1. The generated form layer validates requiredness and the expected selection shape.
2. The backend validation layer checks requiredness, stored value type, and provider-backed value validity.

Three important behaviors to note:

• selectionDynamicProvider chooses the provider used to resolve valid options at runtime
• selectionDynamicProviderCtxt is JSON-decoded before validation and can shape provider behavior
• when the provider context sets validateOnSave to false, save-time provider validation is skipped and only the value-type contract is enforced

selectionDynamic persists the stored provider value rather than the provider's human-readable label.

For single-select fields, that typically means a scalar provider value. For multi-select fields, the value is treated as a collection of provider-backed stored values.

Attrs such as ormType, columnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the field is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because selectionDynamic stores constrained provider-backed values, it is well suited to operational filtering and provider-driven workflows.

Typical use cases include:

• choosing values from a list-of-values provider
• selecting records from a provider-backed business catalog
• narrowing workflows based on provider-defined state or category values

In practice, selectionDynamic is most useful when the option set must remain dynamic without giving up structured persistence.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "couponVenueType",
  "displayName": "Coupon Venue Type",
  "description": null,
  "type": "selectionDynamic",
  "ormType": "varchar",
  "selectionDynamicProvider": "ListOfValuesSelectionProvider",
  "selectionDynamicProviderCtxt": "{\"type\": \"COUPON_VENUE_TYPE\", \"validateOnSave\": false}",
  "selectionValueType": "string",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "isSystem": false
}

This is a representative selectionDynamic field because it shows the core dynamic-selection contract clearly: provider-backed values, provider context, and a runtime-resolved option set.

For many-to-one, SolidX validates in two places:

1. The generated form layer validates requiredness and ensures the user selects a valid related record from the relation control.
2. The backend validation layer accepts either <fieldName>Id or <fieldName>UserKey, checks requiredness, validates the identifier shape, and verifies that user-key based resolution is possible.

Three important behaviors to note:

• the request contract accepts either an integer-style id or the related model's user key
• required validation fails only when both the id and the user key are absent
• if a user key is submitted, the related model must expose a user-key field that can be used for lookup

many-to-one persists a single related reference.

Before persistence, SolidX resolves the submitted id or user key into the related entity and assigns that entity to the DTO. Once resolved, the relation is stored using the configured foreign-key mapping.

Attrs such as ormType, columnName, relationCoModelColumnName, unique, and index are therefore best understood as persistence and schema intent. They shape how the relation is represented in the generated model and storage layer, even when they are not enforced by the validation rules described above.

Because many-to-one points to a single related record, it is a natural fit for relation-aware filters and joins.

Typical use cases include:

• filtering child records by a parent entity such as institute, branch, or customer
• populating related records in form and list flows
• using the related model's user key as the display or search value in metadata-driven UI

In practice, many-to-one is the relation subtype most often used for simple lookup-style business relationships.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "institute",
  "displayName": "Institute",
  "description": null,
  "type": "relation",
  "ormType": "integer",
  "isSystem": false,
  "relationType": "many-to-one",
  "relationCoModelFieldName": "feeTypes",
  "relationCreateInverse": true,
  "relationCoModelSingularName": "institute",
  "relationCoModelColumnName": null,
  "relationModelModuleName": "fees-portal",
  "relationCascade": "cascade",
  "required": true,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "relationJoinTableName": null,
  "isRelationManyToManyOwner": null,
  "relationFieldFixedFilter": "",
  "enableAuditTracking": true
}

This is a representative many-to-one field because it shows the core lookup contract clearly: a single related model, an authored inverse field name, required relation validation, and standard persistence intent.

For one-to-many, SolidX validates the relation using command-style mutation semantics.

The generated form layer validates requiredness and collection shape. The backend CRUD layer validates the command field and then expects one of two payload styles:

• for create, update, and delete, the payload is array-shaped and submitted through the relation value field itself
• for set, link, and unlink, the payload is submitted through <fieldName>Ids

Three important behaviors to note:

• <fieldName>Command controls how the relation should be processed
• clear is a special command that removes all linked children without requiring ids or child payloads
• link and unlink are update-only operations because they need an existing parent record id

one-to-many persists a collection of related child records or links, depending on the chosen command.

In create and update flows, SolidX can create new child entities, preload and update existing child entities, delete child entities, replace the current collection, or perform differential link and unlink operations against an existing parent record.

This makes one-to-many more operationally expressive than scalar fields: it is not just a stored value, but a mutation surface for managing a related collection.

one-to-many is usually queried as a populated child collection rather than as a simple scalar field.

Typical use cases include:

• rendering child rows inside embedded forms or detail pages
• loading child collections through relation-aware populate flows
• applying parent-scoped filters so that only the current record's children are shown or edited

In practice, one-to-many works best when the relation is treated as a managed collection rather than as a list-search field.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "questionPossibleAnswersMaster",
  "displayName": "Possible Response",
  "description": "QuestionPossibleAnswersMaster",
  "type": "relation",
  "ormType": "integer",
  "isSystem": false,
  "relationType": "one-to-many",
  "relationCoModelFieldName": "questionMaster",
  "relationCreateInverse": true,
  "relationCoModelSingularName": "questionPossibleAnswerMaster",
  "relationCoModelColumnName": null,
  "relationModelModuleName": "sapphire",
  "relationCascade": "cascade",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "relationJoinTableName": null,
  "isRelationManyToManyOwner": null,
  "relationFieldFixedFilter": null,
  "enableAuditTracking": true
}

This is a representative one-to-many field because it shows the parent-to-collection contract clearly: a named child model, an explicit child-side inverse field, and the collection semantics needed for embedded CRUD flows.

For many-to-many, SolidX validates the relation using the same command-style mutation pattern used for collection relations.

The generated form layer validates requiredness and collection shape. The backend CRUD layer validates the command field, then expects one of two payload styles:

• for create, update, and delete, the payload is array-shaped and submitted through the relation value field itself
• for set, link, and unlink, the payload is submitted through <fieldName>Ids on the owner side, or through the resolved inverse field name on the inverse side

Three important behaviors to note:

• <fieldName>Command determines how the relation should be mutated
• owner-side versus inverse-side metadata affects which effective field names are used internally
• link and unlink are update-only operations because they need an existing parent record id

many-to-many persists relation membership through a join-style mapping.

In create and update flows, SolidX can create related entities, update or delete related entities, replace the current relation set, or perform differential link and unlink operations against existing records.

The owner-side flag matters here: it determines which side is responsible for the primary relation mapping and how CRUD operations resolve the effective field names.

many-to-many is most valuable when records need to be segmented or navigated through shared tags, categories, permissions, or memberships.

Typical use cases include:

• tagging records with multiple domains or categories
• assigning users, reviewers, or approvers to the same business record
• traversing relation membership through join-aware list and detail experiences

In practice, many-to-many is best treated as a managed membership surface rather than as a scalar search field.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "domains",
  "displayName": "Domains",
  "description": "Domains",
  "type": "relation",
  "ormType": "integer",
  "isSystem": false,
  "relationType": "many-to-many",
  "relationCoModelFieldName": null,
  "relationCreateInverse": false,
  "relationCoModelSingularName": "domain",
  "relationCoModelColumnName": null,
  "relationModelModuleName": "sapphire",
  "relationCascade": "cascade",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "relationJoinTableName": null,
  "isRelationManyToManyOwner": true,
  "relationFieldFixedFilter": null,
  "enableAuditTracking": true
}

This is a representative many-to-many field because it shows the shared-membership contract clearly: a co-model, owner-side metadata, and the join-oriented semantics used by relation-heavy business workflows.

For mediaSingle, SolidX validates the uploaded file collection in the backend CRUD layer.

Three important behaviors to note:

• on create, a required mediaSingle field must receive exactly one uploaded file
• if more than one file is submitted, validation fails because the field is single-valued
• when mediaMaxSizeKb or mediaTypes are authored, the backend validates the uploaded file against those constraints

On update, required validation is intentionally more permissive so that existing media can remain in place when no replacement file is uploaded.

mediaSingle persists through the media subsystem rather than behaving like an ordinary scalar text field.

The uploaded file is stored using the configured storage provider and is then associated back to the business record under the field's media slot. In record responses, the field's asset is typically surfaced through _media.<fieldName> rather than through the plain scalar field value alone.

This makes mediaSingle a hybrid field contract: metadata is authored on the field, but the underlying persistence flow is handled by the platform's media layer.

mediaSingle is usually not used as a direct filter field.

Typical use cases include:

• displaying a primary asset such as a logo or cover image in a list or form
• opening, previewing, or downloading the uploaded file in metadata-driven UI
• populating media payloads alongside the rest of the business record

In practice, media fields are usually queried for display and retrieval rather than for text- or number-style filtering.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "logo",
  "displayName": "Logo",
  "description": null,
  "type": "mediaSingle",
  "ormType": "varchar",
  "isSystem": false,
  "mediaTypes": [
    "image"
  ],
  "mediaMaxSizeKb": 5120,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "mediaStorageProviderUserKey": "default-aws-s3"
}

This is a representative mediaSingle field because it shows the usual single-asset contract clearly: one authored slot, an allowed media family, a size limit, and an explicit storage provider.

For mediaMultiple, SolidX validates requiredness in the backend CRUD layer.

Two important behaviors to note:

• on create, a required mediaMultiple field must receive at least one uploaded file
• unlike mediaSingle, the current backend implementation does not yet apply the same file-type and file-size checks to every uploaded file in the collection

That second behavior is important operationally: mediaTypes and mediaMaxSizeKb express the intended contract for the field, but collection-level enforcement is not yet as complete as it is for mediaSingle.

mediaMultiple persists through the media subsystem rather than behaving like an ordinary scalar field.

Each uploaded file is stored using the configured storage provider and then associated back to the business record under the field's media collection slot. In record responses, the collection is typically surfaced through _media.<fieldName>.

This makes mediaMultiple a natural fit for document bundles, image sets, and attachment-heavy workflows.

mediaMultiple is usually not used as a direct filter field.

Typical use cases include:

• previewing the first item in the collection in list views
• opening the full media bundle in a dialog or lightbox-driven experience
• downloading document-style attachments from the record detail view

In practice, media collections are queried for retrieval and presentation rather than for scalar-style filtering.

Attrs such as private, enableAuditTracking, isSystem, and isPrimaryKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "payByLinkInvoiceFile",
  "displayName": "Pay By Link Invoice File",
  "description": null,
  "type": "mediaMultiple",
  "ormType": "varchar",
  "isSystem": false,
  "mediaTypes": [
    "image",
    "file"
  ],
  "mediaMaxSizeKb": 20480,
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "columnName": null,
  "mediaStorageProviderUserKey": "default-filesystem"
}

This is a representative mediaMultiple field because it shows the collection-style media contract clearly: multiple attachments, a mixed allowed-media policy, and a storage-provider-backed upload slot.

For computed, SolidX does not apply ordinary end-user field validation.

Two important behaviors to note:

• the backend computed-field flow does not apply ordinary user-input validation and therefore returns no direct field errors for submitted values
• generated forms treat the field as read-only and optional because the value is not expected to be provided by the user

This is by design: correctness comes from provider logic and trigger configuration rather than from normal user-input validation rules.

computed persists as an ordinary column value after the platform computes it.

In inline CRUD flows, SolidX parses computedFieldValueProviderCtxt, resolves the named provider, asks that provider to compute the field value, and then assigns the result to the DTO before persistence.

There are two cases where inline computation is intentionally skipped:

• partial updates
• fields that define computedFieldTriggerConfig, because those are expected to be handled by trigger-driven subscriber flows instead

Once computed, the field behaves like any other persisted scalar of the authored computedFieldValueType.

Typical use cases include:

• filtering or searching by generated transaction ids and external ids
• sorting or reporting on derived numeric or date values
• exposing stable business keys that are derived automatically rather than entered manually

In practice, computed is best understood as a generated persisted field rather than as a transient view-only value.

Attrs such as private, enableAuditTracking, isSystem, isPrimaryKey, and isUserKey are part of the field contract even though they are broader than validation alone. They communicate platform-level intent that other parts of SolidX rely on.

{
  "name": "feeTypeUserKey",
  "displayName": "Fee Type User Key",
  "description": "Concatenation of fee type and institute name",
  "type": "computed",
  "ormType": "varchar",
  "isSystem": false,
  "computedFieldValueType": "string",
  "computedFieldTriggerConfig": [
    {
      "modelName": "feeType",
      "moduleName": "fees-portal",
      "operations": [
        "before-insert"
      ]
    }
  ],
  "computedFieldValueProvider": "ConcatEntityComputedFieldProvider",
  "computedFieldValueProviderCtxt": "{\"fields\":[\"feeType\",\"institute.instituteName\"],\"separator\":\"-\",\"slugify\":true}",
  "required": true,
  "unique": true,
  "index": false,
  "private": false,
  "columnName": null,
  "isUserKey": true
}

This is a representative computed field because it shows the full provider-backed contract clearly: an authored value type, a named provider, provider context, trigger configuration, and a generated business key outcome.