Groups

Reference for ticketing groups — the GitOps-declared form of ITSM roles. Groups are how the workflow engine answers “is this user allowed to perform this transition?”: every role: in a workflow points at a group, and group membership (with cascade lookup over the service path) decides who passes the check.

What groups are

Groups are the GitOps-declared form of ITSM roles. A workflow’s role: field always references a group name, never an individual user — on-call rotates, people leave, but the role “db-admins” persists, and pointing transitions at a group means there is always a backup, a deputy, the rest of the team. Individuals are members of groups; transitions belong to groups; the audit trail records the user that performed the action and the group they did it as.

Declaring a group

Minimum — an empty group whose membership is filled later via the UI or LDAP sync:

groups:
  - name: db-admins   # empty group — populated via UI or LDAP sync

Expanded — declare members and/or an LDAP source group inline:

groups:
  - name: db-admins
    users: [alice@local, bob@local]
    ldapGroup: cn=db-admins,ou=groups,dc=acme,dc=com

Both sources are optional. When users: is set, local users are linked by email or username. When ldapGroup: is set, the JIT provisioning layer synchronises membership at LDAP login time — users that authenticate against LDAP and are members of the directory group are added automatically, users that are no longer in the directory group are removed on the next login. The two can coexist: users: for local accounts, ldapGroup: for the directory-backed bulk.

Hierarchical groups

Group names follow the same path-override rule as workflows and catalog items (see Hierarchical naming). A short name lives at the org root; a name containing slashes scopes the group to an env, cluster or service. Use this when you need a different roster per environment, or a service-specific on-call rota.

ticketing:
  org: mlops-app
  groups:
    - name: db-admins                                    # → mlops-app/db-admins (org-wide)
      users: [alice@local, bob@local]
    - name: itops-dev/prod/db-admins                     # env-scoped: only prod
      users: [carol@local]
    - name: itops-dev/dev/c1/postgres-prod/oncall        # service-scoped on-call
      users: [dave@local]

Membership inheritance

A user that is a member of a group at a parent scope is automatically a member of every group of the same name below it. Declare the team once at the most natural scope and the cascade does the rest.

The result is DRY: an env-level DBA team membership applies to every DB service under that env without re-listing the same emails per service.

Cascade lookup

When a workflow transition uses role: db-admins, the backend resolves it against the ticket’s service path by walking from the most-specific group down to the org root, stopping at the first match. Combined with the inheritance rule above, this lets a service-scoped roster override the env-scoped default while still falling back when no override is declared. Full walk-through with diagram in GitOps Setup — Cascade lookup.

Superadmin override

A user with users.is_superadmin = true is treated as an implicit member of every group at every scope, and every workflow transition is allowed for them. This is the standard ITSM break-glass convention — on-call engineers can always step into any role during an incident, even if the explicit group membership has not been provisioned yet. Every superadmin action is still recorded in ticket_status_history with the user id, so the audit trail captures who used the override and when.

Five default groups

The default workflows ship with these four group names baked into their role: fields. Declare them in values.yaml with the rosters that match your org, then the default workflows authorise the right people out of the box.

Using a group in a workflow

Reference the group name in role:. Cascade lookup handles the path resolution; you only need to write the short name unless a specific scope override is intended.

workflows:
  - name: incident_response
    transitions:
      - {from: OPEN,        to: IN_PROGRESS, role: incident-responders}
      - {from: IN_PROGRESS, to: RESOLVED,    role: incident-responders}
      - {from: RESOLVED,    to: CLOSED,      role: any}

The any keyword

role: any is the one reserved value that is not a group name — it means “any authenticated user”. Use it for transitions that anyone holding the ticket should be able to perform (e.g. closing a resolved ticket once the requester confirms the fix). Do not declare a group named any; the keyword takes precedence and the group would be unreachable.

See also

• GitOps Setup — hierarchical naming, cascade lookup, full values.yaml shape.
• Default Workflows — the five default state machines and the groups they reference.
• Overview — ticket lifecycle, priority, audit trail.