Custom fields

Custom fields extend supported remoteEaze records with information required by the organization. Open Foundation → Custom Fields.

Access and lifecycle

• Read Custom Field Definition shows the list and details.
• Create Custom Field Definition shows Create Custom Field and permits a new draft.
• Update Custom Field Definition permits changes and corrections.
• Delete Custom Field Definition permits deletion or restoration when the record state allows it.

Custom-field definitions use maker-checker. The role's Create or Update permission determines how many approvals submission requires, and a checker also needs the matching L1, L2, or L3 authority. A maker cannot authorize their own submission.

See Maker-checker, authorization levels, and amendments.

Create a custom field

1. Select Create Custom Field.
2. At L0, select the target company.
3. Choose the Entity Type that will hold the value.
4. Enter a stable Field Key, user-facing Label, optional description, display order, and whether the value is required.
5. Select the Field Type and configure its value behavior, validation, and display settings.
6. Select Save as Draft, or Save & Submit when it is ready for authorization.

The field key uses lowercase letters, numbers, and underscores and must be unique for that entity within the tenant. Choose it carefully: Entity Type, Field Key, and Field Type cannot be changed after creation.

Field types and value behavior

Available types are String, Number, Boolean, Date, JSON, Array, Computed, and Select.

Depending on the type, a field can use:

• a Static Default used when no value has been entered;
• a Conditional Default selected from ordered condition groups;
• a Computed Value produced from the configured formula.

Conditions within one group use AND. Alternative groups use OR. A conditional default or validation rule can therefore target one precise case or several alternative cases.

A Select field defines label and value pairs. The label is what the user sees; the value is the stable value stored with the record. Changing a label does not change an already configured value key.

A Computed field uses the formula builder and cannot be entered directly by the operator. Use only fields available to the selected Entity Type and verify the preview before authorization.

Configure only validation that matches the selected type. This includes text length or pattern rules, numeric minimum and maximum values, earliest and latest dates, and conditional validation rules. A field can also become required when its conditions match.

Display configuration can add a placeholder, set display order, or mark the field as hidden or read-only. Hidden controls visibility. Read-only permits the value to be displayed without allowing the operator to change it.

Examples

Static default

Create a Select field named Preferred Contact Method, define PHONE and EMAIL as stable values, then use PHONE as the Static Default.

Conditional requirement

Create a String field for Employer Name and make it required when Employment Status equals Employed. Add other conditions to the same group only when every condition must match.

Select field

Define the label High Risk with the stored value HIGH. Reports and integrations use the stable value while forms show the label.

Computed field

Create a Computed field only when its source fields are available on the same Entity Type. Build the expression, test representative inputs, and mark the result read-only so users do not mistake it for entered data.

Submit and authorize

A saved draft does not become an active runtime field. Open it and select Submit for Approval when it is complete. The record progresses through the configured L1, L2, and L3 approvals and becomes available to supported forms only after it is Authorized.

If a checker rejects the definition, correct the draft and resubmit it.

Change an authorized field

Editing an Authorized definition creates an amendment rather than changing the live definition immediately. Submit and authorize the amendment to apply the new label, validation, default/value behavior, display order, or UI settings. Deletion and restoration of an Authorized definition also follow the amendment lifecycle.

The existing Authorized version remains the effective definition while its amendment is pending.