Custom Fields And Tags

Custom fields collect answers. Ticket custom fields collect them at ticket submission. Project custom fields collect them on a project record. Tags label work that someone can already see. This page covers all three.

Before you start

• You need SystemAdmin access and step-up verification.
• For a ticket field, the owning service must already exist. See Services and the Service Catalog.
• Decide the stable key, the field type, and whether the answer is required before you open the workspace. Changing a field type after values exist is a data change, not a rename.

Definition, binding, and value

Three records are involved, and they are separate.

Changing a shared definition does not change existing bindings. Binding a shared definition copies its field contract at that moment. Later edits to the shared definition apply to bindings created after the edit. Existing bindings, and the values already stored against them, keep the contract they were created with. There is no automatic migration of type, choices, candidate scope, or time-zone meaning. If you need existing bindings to change, review and change each one.

You can also create a field that belongs to one service only. A service-specific field has no shared definition behind it.

Supported field types

Both ticket fields and project fields use the same list.

• Text, Text Area, Number, Date, Date and time
• Select (Dropdown), Multi-Select, Checkbox
• Email, Phone, URL — the web-address field
• Project reference, Rich content
• User picker, Multi-user picker

For Date and time, you choose the field's time zone. The server reads the submitted local time in that zone and stores one Coordinated Universal Time (UTC) instant.

For User picker and Multi-user picker, you choose the candidate scope:

• Directory users — any active internal user can be referenced.
• Department workers — only active internal users with current Work access in the owning department can be referenced.

A stored user reference is a record of a name. It gives the referenced person no access to the ticket or project.

Rich content accepts the product's structured document format. It does not accept raw or executable markup. Rich content on a project does not accept pictures in this release.

Add a ticket custom field to a service

1. Open the service and select Intake handoff, then Open dedicated custom-fields workspace.
2. In Custom Fields, confirm exactly one service is selected.
3. Choose either a new service-specific field or an existing shared definition.
4. Select the field type.
5. Enter the label, the help text, the sort order, and whether the answer is required.
6. Complete the settings the workspace shows for that type. For Select (Dropdown), enter the options and choose Intake presentation: Dropdown, Vertical, or Horizontal. For Multi-Select, choose Option layout: Vertical or Horizontal.
7. Save once.
8. Preview the form and submit one test ticket with a valid answer and one with an invalid answer.

A service may have at most one Project reference field.

Make a field appear only in some cases

A conditional rule shows a field only when another field on the same form has a particular value. The controlling field is chosen under Controlling field, which defaults to Always show.

1. Choose the Controlling field.
2. Choose the operator.
3. Choose the value that makes the dependent field apply. You pick it from the controlling field's own options — you do not type it.
4. Decide whether the dependent field is required while it applies.
5. Save.
6. Submit a test ticket down the matching path and one down the non-matching path.

What can control a condition

Only three field types can be a controlling field: Select (Dropdown), Multi-select, and Checkbox. Free-text, date, and the other types are not offered in the Controlling field list at all. If the field you wanted to branch on is not there, that is why.

This is deliberate, and it follows from how the value is chosen: because you pick the comparison value from the controlling field's option list, the controlling field has to have options. A checkbox offers true and false.

The operators

Which operators you are offered depends on the controlling field's type.

Is and Contains are the same test, named for the field they apply to. Both mean "the submitted value is this option". On a multi-select, where several options can be chosen at once, "contains" is the natural word for it.

Contains does not search text. It does not match part of a word or part of a longer answer — there is no way to write a rule such as "when the summary mentions outage". Matching is exact, and case does not matter.

Has any value and Has no value take no value of their own. Use them to branch on whether the controlling field was answered at all.

Combining rules

Rules combine with AND. Every rule must pass. There is no OR, and no way to express one — a condition such as "show this when the department is Facilities or Estates" cannot be built. Where the controlling field is a multi-select, a single Contains rule can cover several options at once, which is often enough.

A condition with no rules always shows the field, which is the same as leaving Controlling field on Always show.

Other limits

A value submitted for a field that does not currently apply is rejected. You cannot delete a field while another field's condition still refers to it — remove the condition first.

Route an owner from a select option

A Select (Dropdown) option can propose an owner when the ticket is created.

1. Open the select field's options.
2. On the option, choose one active internal user with Work or stronger access in the service's department.
3. Save, then create one test ticket for each option.

The chosen person is re-checked when the ticket is created. If they are missing, inactive, or no longer eligible, no owner comes from this source and ticket creation continues. This is one of several assignment sources; see Assignment rules.

Add a project custom field

Project fields are configured in the same Custom Fields workspace, in Projects mode. Every project field starts from a shared definition.

1. Open Custom Fields and select Projects.
2. Complete step-up verification when prompted.
3. Under Shared field library, select Add shared field.
4. Enter the Shared key, or leave it blank to derive one from the field name.
5. Enter the Default field name and choose the field type.
6. Enter the default help text. For Select or Multi-Select, enter one choice per line.
7. If your organization approves it, expand Shared validation rules and enter the rules in JavaScript Object Notation (JSON).
8. Select Create shared field once.
9. Confirm the definition card shows the expected key, type, option count, and active binding count.

Then bind the definition to projects.

1. Select the definition.
2. Under Project association, set the Project detail label, Sort order, Project detail help text, Option layout for a multi-select, and Required on Project details.
3. Under Project association target, choose Selected projects or All projects.
4. For Selected projects, filter the roster and select each project card. Read the target count. Filters narrow what you can see without clearing what you have selected, so a project stays selected after it drops out of the filtered roster. Selecting a definition starts you from the projects it is already applied to, not from an empty set.
5. For All projects, read the Projects in tenant count. Filters help you review the roster but do not narrow the target — every current project receives the binding.
6. Select Apply to projects once.
7. Confirm the reported target, created, and updated counts.
8. Open one project, select More info, and confirm the field appears.

All projects targets the projects that exist now. It is not a rule for future projects. After new projects are created, review the Without fields list and apply the field again where you need it.

Remove a field from projects

Remove from projects takes the binding off the projects you have targeted. Select the definition, target the projects the same way you would to apply it, then select Remove from projects once and read the reported counts.

Removal deactivates the binding rather than deleting anything. The field stops appearing on those projects and stops being collected there. Values already stored on a project record are left alone, so re-applying the field later brings them back into view.

Applying to a selected set also removes. With Selected projects, what you select becomes the whole saved set for that definition: any project holding the binding that is not in your selection has it removed by the same action. This is what makes the field correctable — the same control fixes a mis-targeted binding — but it also means an apply can quietly take the field off projects you did not think you were touching. Before selecting Apply to projects, check the target count against the projects you meant to end up with, not just the ones you are adding. All projects adds without removing.

Test with a small selected set before using All projects.

Project field values stay on the project record. They do not copy to linked tickets, change staffing, assign owners, move a workflow status, or change SLA timing.

Maintain project field values

Project managers and owning department managers can edit values on projects they steward. They cannot create shared definitions or change bindings.

1. Open the project.
2. Select More info, then Edit details.
3. Complete the configured fields, including every required value.
4. Select Save changes.

Create a tag

A tag is a label for filtering. It changes nothing else.

1. Open Tags. The list shows ticket tags, project tags, and retired tags.
2. Enter a Stable key, a Display name, an optional Group key, and a Sort order.
3. Choose whether the tag applies to Tickets, Projects, or both.
4. Leave Active selected. Clear it only to stop the tag being applied to new work.
5. Select Create tag once.
6. Confirm the tag offers itself only on the target types you chose.

A tag does not change who can see a ticket or project, who owns it, its workflow, its SLA, or how it is routed.

Related pages

• Services and the Service Catalog
• Assignment rules
• Glossary
• Limits and scope