Custom fields
Task walkthrough: Define custom fields. This page is the full configuration and troubleshooting reference.
Custom fields let an administrator add their own metadata fields. Definitions are tenant-global, and today they apply to jobs.
Definition fields
| Field | Notes |
|---|---|
name | Unique per tenant. |
inputType | One of: text, number, boolean, select, date, textarea. |
isRequired | Whether a value is required (default off). |
defaultValue | Optional default. |
options | The choices — required for select, ignored otherwise. |
description | Optional. |
displayOrder | Controls ordering in the UI. |
Where values are set
A definition creates a field; the value is set per job, in the job editor's Custom Fields section. That section appears in both job editors:
| Where | What you are editing | Required fields |
|---|---|---|
| The Workflow View job editor, in the workflow editor | The job definition — every future build reads it | Enforced. A required field with no value blocks the save. |
| The Process View job editor, on a built job instance | That instance only — see Editing a job on a running instance | Not enforced. |
Earlier builds showed the section in the Workflow View only, so a job's custom fields were invisible on the Process View and could not be corrected on a run that was already going.
Why an instance save is not held to a required field. The instance's custom-field values are fixed when the workflow is built, so a field you marked required after that build has no value on the instance to check. Enforcing it there would refuse an unrelated edit on a run the platform is perfectly willing to accept. The definition is where the rule belongs, and that is where it is applied.
Push Changes to Workflow carries custom fields, and carries them field by field rather than replacing the whole set — so a definition added since the build keeps the value it has on the workflow, instead of being wiped by an instance that never had a value for it. Clearing a field on the instance and pushing does clear it on the definition: that is an edit you made, and it travels.
- Custom fields currently apply to jobs. The model is extensible to other object types, but there is no per-object-type assignment in the UI today, so custom fields are not yet available on other objects.
- A select field needs options; an empty options list isn't valid.
- Values are stored as strings and interpreted per
inputTypewhere used. - A validation message names the job it's about, not just the field — a missing required value,
a value of the wrong type, a value outside a
selectfield's options, or a reference to a field that no longer exists all report which job carries the problem. - A job editor lists the first 100 definitions. Both editors read the definition list one page at a time and neither asks for a second page, so a tenant with more than 100 custom fields will not see them all in the editor. Keep the set to what you use.