Skip to main content
A field that holds catalog entities — a Catalog custom field, or a native field such as Services or Teams — can be filled in automatically from another catalog field on the same incident, using a relationship your catalog already describes. The usual shape: someone declaring an incident picks the Team, and the Services field fills itself with the services that team owns. Nobody looks anything up, and the incident is tagged correctly whether or not the responder knows which services sit behind that team.

​
What Makes It Possible

Auto-setting reads a property on the source catalog that points at the target catalog. A Services field can be set from a Team field only because the Team catalog has a Services property. The relationship is data you have already modelled; auto-setting just follows it at incident time.
If the relationship does not exist in the catalog, there is nothing to follow. Model the property first — a Team entity that does not know its services cannot populate a Services field.

​
Pairing Rules

Two rules limit which pairings you can configure:
  • A field can be auto-set from one catalog property, not several. You cannot fill Services from Team and from Application.
  • Automatic values do not chain. Once a field is set automatically, the properties of its catalog cannot auto-set other fields. If Services is filled from Team, a Service property cannot then fill a third field. The rule applies across all of your incident fields, not per form.
One catalog can still drive several fields — a Team catalog with both a Services property and a Functionalities property can fill both. The field picker greys out the combinations this rules out, so you find the constraint while configuring rather than after saving. If you need a field populated from more than one place, a workflow is the mechanism — see below.

​
Why It Is Worth Setting Up

The argument is not keystrokes saved. It is that the fields get filled correctly and consistently, by people who do not have the ownership map memorised. Service tagging is the field most often left blank or guessed at during a real incident, and it is the field most of the useful analysis depends on afterwards. An incident tagged with the wrong services is worse than one tagged with none — it pollutes every report that groups by service, silently, and nobody goes back to correct it. Auto-setting moves that correctness out of the responder’s head and into the catalog, where it is maintained deliberately by people who are not mid-incident.

​
What It Does Not Do

  • It does not override the catalog. The values come from the relationship as modelled. If a team’s service list is stale, the incident inherits the stale list, so a catalog that drives fields is a catalog worth keeping current — see Catalog Sync.
  • By default, it does not lock the field. A responder who knows better can change what was filled in. Some organizations can also mark a field non-editable on a form, in which case the automatic value cannot be overridden.
  • It is not a workflow. Workflows can also set fields, but the Update Incident action replaces a field’s entire list rather than adding to it, which can clear values another workflow set earlier. Auto-setting from the catalog is the gentler mechanism; reach for a workflow when you need conditional logic the catalog relationship cannot express.

Custom Fields

Field types, including the Catalog field this builds on.

Catalog Sync

Keeping the catalog current, which is what keeps auto-set values right.

Managing Custom Catalogs

Adding the cross-catalog property this feature follows — the prerequisite above.