Ticketing configuration

There is no admin screen for workflows, catalogue items or the organisation. They are YAML files mounted into the core from the chart's ticketing/ directory and read at start. Editing them means changing files and running helm upgrade. That is the trade the platform makes on purpose: the ticket process is configuration, configuration lives in Git, and a UI that let somebody click it into a different shape would make the two drift apart.

The directory

ticketing/
├── org.yaml                  # org: corp
├── workflows/
│   ├── incident-response.yaml
│   ├── major-incident.yaml
│   ├── service-request.yaml
│   ├── access-request.yaml
│   ├── change-request.yaml
│   ├── emergency-change.yaml
│   └── problem-investigation.yaml
└── catalog/
    ├── incidents.yaml
    ├── requests.yaml
    ├── access.yaml
    ├── changes.yaml
    └── problems.yaml

Mounted at /etc/itops/ticketing (ITOPS_TICKETING_CONFIG_PATH), only when the ticketing plugin is enabled. Files are merged: every workflows: list and every catalog.items: list across the directory becomes one registry, so splitting by team or by category is fine.

Changing it

helm pull itops/itops --version 2.0.0 --untar
cd itops/ticketing
# edit, add or remove files
cd ../..
helm upgrade itops ./itops -n itops -f values.yaml

Keep the untarred chart in your GitOps repository; upgrades are a helm pull of the new version plus a three-way merge of ticketing/. A file that does not parse is reported in the core log at start; check the log after every upgrade that touched the directory.

Workflows

A workflow is a name, a display name and a list of allowed transitions. Each transition names the group whose members may make it, or any.

workflows:
  - name: incident_response
    displayName: "Incident Response"
    transitions:
      - {from: OPEN,        to: IN_PROGRESS, role: incident-responders}
      - {from: IN_PROGRESS, to: RESOLVED,    role: incident-responders}
      - {from: IN_PROGRESS, to: ON_HOLD,     role: incident-responders}
      - {from: ON_HOLD,     to: IN_PROGRESS, role: incident-responders}
      - {from: RESOLVED,    to: CLOSED,      role: any}
      - {from: RESOLVED,    to: IN_PROGRESS, role: any}

Statuses are OPEN, IN_PROGRESS, ON_HOLD, RESOLVED, CLOSED. A transition that is not listed does not exist: the UI does not offer it and the API refuses it. The group named in the first transition out of OPEN is the queue a new ticket lands in.

The seven shipped workflows all have the same five-status shape and differ in which group works the ticket and who may close or reopen it:

The catalogue

Categories give the request form its sections; items are what a person picks. An item names its workflow, its defaults and, optionally, its own SLA promise.

catalog:
  categories:
    - name: incidents
      displayName: "Incidents"
      icon: report_problem
      order: 1
      note: "Use these when a service is broken or behaving incorrectly."
  items:
    - name: outage_report
      category: incidents
      displayName: "Service Outage"
      description: "Production service is unreachable or fully unavailable."
      icon: cloud_off
      workflow: incident_response
      defaults: {priority: CRITICAL}
      sla: {responseMinutes: 15, resolutionMinutes: 240}
      order: 1
      featured: true

sla on an item overrides the priority-driven deadlines for tickets raised from it. featured puts the item on the front of the request form. Icons are Material icon names.

The shipped catalogue has about thirty items across five categories. Incidents: outage_report, major_outage, degraded_performance, network_issue, general_issue. Requests: password_reset, software_request, hardware_request, email_distribution_list, printer_setup, meeting_room_av. Access: vpn_access, new_employee_onboarding, employee_offboarding, privilege_elevation, access_request. Changes: emergency_fix, infra_change, application_deployment, database_change, dns_change, certificate_renewal. Problems: recurring_issue, performance_pattern, capacity_planning.

A service's registration names the item that templates its automatic incident ticket with incidentCatalogItem.

Groups

A workflow's role: names a group. Four ITSM groups ship with the platform and are what the default workflows reference:

Groups are database rows, managed on the Users page or upserted from the chart's groups/*.yaml at core start. Membership is what gives a person the right to make a transition; the four platform roles decide what they may do outside a workflow.

Hierarchical lookup

A role: reference is resolved by walking up the service's path, most specific match first:

corp/commerce/prod/eu-central-1/payment-gateway   → payment-gateway's own groups
corp/commerce/prod/eu-central-1                   → cluster-level groups
corp/commerce/prod                                → environment-level
corp/commerce                                     → platform-level
corp                                              → organisation-level (org.yaml)

So role: oncall can mean the payments on-call for payment tickets and the platform on-call for everything else, without a workflow per service. Group names may carry the path form (prod/eu-central-1/db-admins); the chart flattens slashes to dashes for file names and keeps the path in the group's name.

org.yaml holds the organisation prefix (org: corp in the shipped chart); it is the top of that walk.

Reloading

The registry is read when the core starts. helm upgrade with changed files rolls the core and reloads it. In development builds the /api/v1/dev/registry/reload endpoint reloads without a restart; it is not compiled into release images.

What is not configurable here

Users, passwords and memberships: runtime data, managed in the UI or through LDAP. SLA definitions: the SLA plugin's own, exported and imported as YAML through /api/v1/templates. Ticket fields themselves: the model is fixed; what varies per installation is which fields each group may see or edit, through field-level permissions.