---
title: "Putting the catalog to work"
description: "What a filled-in catalog buys you, from owning-team alert routing to catalog-backed incident fields and agent-readable ownership data."
canonical: https://firefight.app/docs/catalog/using-catalog/
---

# Putting the catalog to work

The catalog pays off in three places. Alerts route by ownership, incident fields stay structured, and the same map is readable by the API and by AI agents you connect. This page covers each payoff and what the catalog needs to contain for it to work.

## Alert routing by ownership

When an alert arrives carrying a `service`, `team`, `environment`, or `functionality` field that names a catalog entry by slug, Firefight enriches the alert with catalog context before routing rules run.

- Related entries one hop away are merged in. An alert with only `service: checkout` also gets `team` filled from the service's owner team.
- The entry's attributes become dotted fields, so a rule condition like `service.tier` `is one of` `Critical` routes by catalog metadata the alert never sent.
- When you write a condition on a catalog field, the value picker offers your catalog entries directly.

Routing outcomes can then target ownership instead of hardcoded names.

| Outcome | What the catalog resolves |
|---|---|
| Notify the owning team's channel | The service's own Slack Channel attribute wins when set, otherwise the owner team's channel |
| Invite the owning team | The owner team's members and manager are invited to the incident channel |

Resolution happens at fire time, not when you save the rule. Reorganize ownership in the catalog and every rule follows without edits. When something cannot be resolved, for example a service with no owner team or a team with no channel set, the incident is still created and the gap is recorded as a note on it. See [Routing rules](https://firefight.app/docs/alerts/routing-rules.md) for the full rule reference.

:::tip
For owning-team routing you need exactly three things. The alert's `service` field matches a service entry's slug, that service has its Owner Team set, and the team has its Slack Channel, Members, or Manager attributes filled in.
:::

## Catalog-backed custom fields

Custom fields under **Settings → Custom Fields** can draw their options from the catalog instead of a hand-maintained list.

- A **Catalog reference** field stores one catalog entry, and a **Catalog multi-reference** field stores several. Point the field at a type, such as Service, and responders pick from your real services.
- Single-select and multi-select fields can also choose **From catalogue** as their option source, using a type's entries as the choices.

Attach these fields to the incident lifecycle forms under **Settings → Forms** and an "Affected services" field becomes structured data that always matches the catalog, instead of free text that drifts.

## Readable by agents and the API

The catalog is part of Firefight's readable surface for external tools.

- The REST API exposes types and entries under `/api/v1/catalog/`, listed in [Entries, attributes & relationships](https://firefight.app/docs/catalog/entries-and-attributes.md).
- AI agents connected over MCP get a catalog search tool. An agent investigating an incident can ask which team owns a service, find its Slack channel, and follow relationships between entries, with member attributes resolved to display names. Connections are managed under **Settings → API Keys**, and access is read-only.

Because agents, the API, alert routing, and incident fields all read the same entries, keeping the catalog current in one place keeps every consumer current at once.