Service Catalog

TICKETING — PAID PLUGIN

A ServiceNow-style catalog of pre-filled ticket templates. Users browse cards by category, click one, fill in one or two fields, and the rest (priority, assignee group, workflow, SLA) is set automatically. The whole catalog is GitOps-declared in Helm values — no in-app editor.

What it is

The service catalog is the front door for non-technical users. Instead of asking everyone to learn the difference between HIGH and CRITICAL, or which group handles network problems, you publish a set of named cards: “Network Outage”, “Access Request”, “New VM”. The user clicks the one that matches their situation, types a short description, and submits.

Each card behind the scenes is a pre-filled ticket template — the platform fills in priority, assignee group, workflow and SLA target from the YAML, then opens a normal ticket. From the moment of submission the catalog item is gone: the rest of the lifecycle is plain ticketing.

Why GitOps, not a UI editor

Catalog content is operational policy: who handles what, what counts as an incident vs a request, what the response time should be. That policy belongs in Git, next to the rest of your infrastructure, for three reasons:

Auditable. Every change to the catalog is a commit, with an author, a timestamp and a diff. Compliance reviewers love this.
Reproducible. A new ITOps install gets the same catalog by re-applying the same Helm values. No “export from prod, import to staging” dance.
LLM-friendly. The YAML schema is small enough that you can hand a prompt like “add a category for storage requests with three items” to an AI assistant and get a correct diff. See AI Prompts.

YAML declaration

Catalog content lives under ticketing.catalog in your Helm values. The shape:

ticketing:
  catalog:
    categories:
      - {name: incidents, displayName: "Incidents", icon: report_problem}
      - {name: requests,  displayName: "Requests",  icon: assignment}
    items:
      - name: network_outage
        category: incidents
        displayName: "Network Outage"
        description: "Connectivity or DNS failure"
        icon: wifi_off
        workflow: incident_response
        defaults: {priority: HIGH, assigneeGroup: network-team}
        sla:      {responseMinutes: 15, resolutionMinutes: 240}
      - name: access_request
        category: requests
        displayName: "Access Request"
        workflow: incident_response
        defaults: {priority: MEDIUM}
        sla:      {responseMinutes: 60, resolutionMinutes: 1440}

Field reference:

Field	Required	Purpose
`name`	yes	Stable identifier. Used as the foreign key on tickets.
`category`	yes	Must match a declared category `name`.
`displayName`	yes	Card title shown to users.
`description`	no	Card subtitle. Shown under the title.
`icon`	no	Material Symbols name. Defaults to a generic ticket icon.
`workflow`	yes	Must match a declared workflow under `ticketing.workflows`.
`defaults.priority`	no	Pre-filled priority. User can override.
`defaults.assigneeGroup`	no	Group that auto-receives the ticket.
`sla.responseMinutes`	no	SLA target for first response. If omitted, falls back to priority defaults.
`sla.resolutionMinutes`	no	SLA target for resolution. If omitted, falls back to priority defaults.

Incremental: start small, grow over time

Today you might ship a catalog with four items. In a month you notice that “new mailbox” requests are coming in as “Access Request” with confusing free-text descriptions. You add a fifth item:

- name: new_mailbox
  category: requests
  displayName: "New Mailbox"
  description: "Create or migrate a mailbox"
  icon: mail
  workflow: incident_response
  defaults: {priority: LOW, assigneeGroup: it-helpdesk}
  sla:      {responseMinutes: 240, resolutionMinutes: 2880}

Helm upgrade. The card appears. Existing tickets are untouched, the new card starts catching new requests. No downtime, no migration, no UI form to maintain.

Reconciliation behaviour

On every chart upgrade the plugin reconciles the declared catalog against the database:

New item or category — inserted.
Existing item with changed fields — updated in place. Tickets already opened from this item keep their original snapshot of priority/SLA — only future tickets pick up the new values.
Item removed from YAML — soft-deleted: hidden from the catalog page, but not purged from the DB. Existing tickets continue to reference it. Re-adding the same name later restores the card without losing history.

Example flow

User clicks “Network Outage” card.
Form opens with priority pre-filled to HIGH, assignee group network-team, SLA 15min/4h, workflow incident_response.
User types title (“DNS resolution failing in eu-west-1”) and a one-line description.
Submit → ticket created in OPEN, network-team gets notified, SLA timer starts.
From here on it is a normal ticket; see Tickets for the rest of the lifecycle.