Default Workflows

TICKETING — PAID PLUGIN

Reference for the five workflow templates that ship with the ticketing plugin. Every workflow is a state machine over the same fixed four-state model (OPEN → IN_PROGRESS → RESOLVED → CLOSED); they differ only in who is allowed to perform each transition. Pick one per catalog item, or copy a workflow into your values.yaml as a starting point and tweak the role on individual transitions.

Status and priority enums

Both enums are fixed by the plugin — you cannot add custom values.

Enum	Allowed values
`status`	`OPEN`, `IN_PROGRESS`, `RESOLVED`, `CLOSED`
`priority`	`LOW`, `MEDIUM`, `HIGH`, `CRITICAL`

Each transitions[].role is one of assignee (the user the ticket is assigned to), requester (the user who opened it), or any (either side, plus admins).

Workflow summary

Name	Use case	Special trait
`incident_response`	Operational incident	Requester confirms the fix worked
`service_request`	General service request	Either side may close
`change_request`	Change management	Implementer self-verifies and closes
`problem_investigation`	Root cause analysis	`IN_PROGRESS` → `OPEN` backtrack allowed
`access_request`	Access provisioning	Requester explicitly confirms access works

incident_response

Default workflow for operational incidents — production outages, payment failures, anything where the requester is the one experiencing the problem and only they can verify the fix worked in their environment.

- name: incident_response
  displayName: "Incident Response"
  transitions:
    - {from: OPEN,        to: IN_PROGRESS, role: assignee}
    - {from: IN_PROGRESS, to: RESOLVED,    role: assignee}
    - {from: RESOLVED,    to: CLOSED,      role: requester}
    - {from: RESOLVED,    to: IN_PROGRESS, role: any}

The assignee resolves; the requester confirms. Either side can re-open from RESOLVED if the fix did not stick. Use this as the default for anything CRITICAL or HIGH from the Service Catalog.

service_request

For general service requests where any party can close the ticket once the work is visibly done — for example, “please copy this file” or “rotate this credential”. The requester typically closes because they are the first to see the result, but the assignee can close too if the requester goes quiet.

- name: service_request
  displayName: "Service Request"
  transitions:
    - {from: OPEN,        to: IN_PROGRESS, role: assignee}
    - {from: IN_PROGRESS, to: RESOLVED,    role: assignee}
    - {from: RESOLVED,    to: CLOSED,      role: any}
    - {from: RESOLVED,    to: IN_PROGRESS, role: requester}

Lower friction than incident_response. Re-open is requester-only because the assignee already signed off when they marked it resolved.

change_request

For planned changes where the implementer is also the verifier — e.g. a database upgrade, a chart bump, a config rollout. The assignee both moves the ticket through resolution and closes it, because they are the one who can confirm the change landed correctly. A two-phase model: IN_PROGRESS → RESOLVED means “deployed”; RESOLVED → CLOSED means “verified, no rollback needed”.

- name: change_request
  displayName: "Change Request"
  transitions:
    - {from: OPEN,        to: IN_PROGRESS, role: assignee}
    - {from: IN_PROGRESS, to: RESOLVED,    role: assignee}
    - {from: RESOLVED,    to: CLOSED,      role: assignee}
    - {from: RESOLVED,    to: IN_PROGRESS, role: any}

Either side can re-open during the verification window if monitoring reveals a regression.

problem_investigation

For deep-dive root cause analysis where it is normal to step back to OPEN after picking the ticket up — e.g. you start investigating, find the issue belongs in a different area, return it to the queue for re-triage. Most other workflows treat IN_PROGRESS → OPEN as illegal; this one explicitly allows it.

- name: problem_investigation
  displayName: "Problem Investigation"
  transitions:
    - {from: OPEN,        to: IN_PROGRESS, role: assignee}
    - {from: IN_PROGRESS, to: OPEN,        role: assignee}
    - {from: IN_PROGRESS, to: RESOLVED,    role: assignee}
    - {from: RESOLVED,    to: CLOSED,      role: any}
    - {from: RESOLVED,    to: IN_PROGRESS, role: any}

The backtrack transition is restricted to the current assignee — only they can hand the ticket back, not the requester. Once resolved, either side may close or re-open.

access_request

For access provisioning — new accounts, group membership, VPN credentials, kubeconfig handover. The requester is the only person who can verify that the access actually works end-to-end (the assignee can grant it but cannot test it from the requester's machine), so closing the ticket is requester-only.

- name: access_request
  displayName: "Access Request"
  transitions:
    - {from: OPEN,        to: IN_PROGRESS, role: assignee}
    - {from: IN_PROGRESS, to: OPEN,        role: any}
    - {from: IN_PROGRESS, to: RESOLVED,    role: assignee}
    - {from: RESOLVED,    to: CLOSED,      role: requester}

The IN_PROGRESS → OPEN backtrack is open to either side: the assignee can hand it back if it needs another approver; the requester can hand it back if they realise their request was incomplete. Note there is no RESOLVED → IN_PROGRESS re-open path: if the access doesn't work, the requester closes the ticket as failed and opens a fresh one (cleaner audit trail than a resurrected ticket).