Skip to main content
Catalog entries link to each other through their attributes: a service has an owning team, and that team has a Slack channel, a Slack user group, and an escalation path. Workflows, alert routes, and custom fields can follow those links, so a single configuration finds the right people for whichever service is affected, instead of needing one workflow per team.

Model the relationships

Relationships come from attributes whose type is another catalog type. When you add an attribute to a catalog type, the Reference types include your own catalog types and the ones incident.io provides, such as:
  • Slack Channel and Microsoft Teams Channel, for where a team talks
  • Slack User Group, for who to invite
  • Escalation Path and Schedule, for who to page
  • User, for a specific person
A common model is a Service type with an Owning team attribute, and a Team type with Slack channel, Slack user group, and Escalation path attributes. See What data should I bring into Catalog? for more examples, and How do I get data into Catalog? to populate them. Then add a Catalog-backed custom field, like Affected services, so each incident records which entries it affects.

Follow relationships in workflows

When a workflow step or condition asks for a value, the variable picker lets you step through an entry’s attributes. For example, to invite the teams that own the affected services, pick Incident → Affected services → Owning team → Slack user group in the Invite user or group to the incident’s channel step. Use the arrow keys, or click an item, to move in and out. The picker only lists variables that fit the field, so a path can seem to be missing:
  • Anything reached through a multi-value field is a list. An incident can have several affected services, so Affected services → Owning team → Slack channel is a list of channels. It appears in steps that take several values, but not in a step that takes one channel, like Send message to a channel. For those, choose what you want to happen: a loop runs the step For each value of the list, like posting in every affected team’s channel, and a Query ending in First picks one value, like a single channel to post in.
  • The picker goes a few levels deep. For a longer path, use a Query expression, which can follow as many links as you need.
  • The trigger decides what’s available. An incident trigger can’t see an alert’s attributes. To use those, start the workflow from an alert is attached to an incident instead.

Query expressions

When you need to do more than follow a link, add a Query expression. See How to use Workflow Expressions. A Query starts from a value and applies steps in order:
  • Navigate follows an attribute to a related entry, like from a service to its team. From a list, it returns a list.
  • Filter keeps the entries that match your conditions.
  • First, Maximum, Minimum, and Random pick one entry from a list.
  • Count and Sum turn a list into a number.
  • Merge combines the result with another variable of the same type.
To fill a field that takes one value from a list, end the Query with Filter and then First. Don’t rely on First alone when the order of the list doesn’t mean anything, like the teams a person belongs to. If a required field could end up with no value, set a default in the expression. Otherwise the step can’t run for incidents where the path is empty. To skip those incidents altogether, add a condition to the workflow instead.

Templates

Several workflow templates are built this way, including Notify responders about new incidents, Invite the affected team to an incident, and Escalate via incident.io. When you create one, it finds a path through your Catalog from the incident to the channel, user group, or escalation path it needs.

Follow relationships in alert routes

When your alert attributes are Catalog-backed, an alert route can use them the same way. Under How should alerts be escalated?, choose to escalate using the alert’s attributes, and the route suggests paths from the alert to an escalation path, like Alert → Team → Escalation path. See Alerts and teams for a walkthrough. The route’s incident template can set custom fields from the alert’s attributes too, so incidents created from alerts arrive with their affected services and teams already filled in. This depends on the alert’s attribute matching a catalog entry:
  • The value must match exactly. It’s compared, case-sensitively, with each entry’s ID, external ID, and aliases, and with its name if the catalog type has Reference entries by name turned on. If more than one entry matches, the external ID wins, then an alias, then the name.
  • If nothing matches, the attribute is left empty, without an error. Anything the route derives from it is empty too, so no one is paged from that path.
Set a fallback escalation path on the route, so an alert that doesn’t match still reaches someone.

Derive one field from another

A custom field can fill itself in from another one. Set Affected teams to Set automatically, and use an expression that navigates from Affected services to each service’s owning team. Responders pick the service, and the team follows. See Set a custom field automatically.

Connect people across tools

People have accounts in many tools, and the Catalog links them. Each external user type, like Github User, PagerDuty User, or Sentry User, has an incident.io User attribute that points at the person’s incident.io account. Many integrations link accounts automatically when you connect them. GitHub and Jira accounts are never linked automatically: each person connects their own from their connected accounts settings, or an admin links them from the User catalog type. A step that needs a person, like Invite user or group to the incident’s channel or Assign incident roles, takes an incident.io user. To use someone from another tool, navigate to their incident.io User. For example, if your Service type has a Code owner attribute of type Github User, pick Incident → Affected services → Code owner → incident.io User in the invite step to invite the code owners of the affected services. If someone isn’t linked, their incident.io User is empty, so the step leaves them out and still runs for everyone else. Slack users are the exception: a Slack User can fill a user parameter directly.