Define custom fields
Custom fields let you add your own metadata to capture information that matters to your organization. Custom fields apply to jobs.
The metadata your organization needs to track on a job (an owner, a ticket number, a cost center) has nowhere to live, so it ends up crammed into job names or simply isn't captured.
Field types
| Type | Use for |
|---|---|
| Text / Text area | Short or long free text |
| Number | Numeric values |
| Boolean | Yes/no |
| Select | A fixed list of choices (you provide the options) |
| Date | A date |
Create a custom field
To define a custom field, complete the following steps:
- Go to Custom Fields and add a field.
- Enter a name and choose an input type.
- For a select field, add the options.
- Optionally set it required, give it a default value and a description, and set its display order.
- Save.
- A select field must have at least one option.
- Set display order to control where fields appear.
- Custom fields apply to jobs today.
- Keep the set small: a job editor lists the first 100 definitions.
Where the values get filled in
Defining the field is your job; filling it in is the builder's and the operator's. The field appears in a Custom Fields section in both job editors:
- in the workflow editor, on the job definition — this is where a required field is enforced;
- in the Process View, on a job of a build that is already running, where an operator can correct a value mid-run.
A field you mark required after a workflow has been built is not enforced on that build's jobs. Their values were fixed when the build ran, so there is nothing on the instance to check, and refusing an operator's unrelated edit over it would be unhelpful. The requirement applies from the next time somebody saves the job's definition. See Where values are set.
Related topics
- Custom fields — full configuration reference and troubleshooting
- Manage workspaces (Administrator)