Statuses and states

Every activity has two related notions of “where it is in its lifecycle”:

• State — the coarse lifecycle: open, closed, or pending. The state drives behavior: closing archives the activity and fires onConclude; reopening un-archives it.
• Status — the finer, app-defined value shown and selected in the UI (open, in_progress, on_hold, …). Each status maps to one state.

Changing the status can move the state (selecting a closed-state status concludes the activity), and changing the state updates the status to that state’s default. External systems (Zendesk, Jira) sync against the state, with status preserved where a mapping exists.

Activity states

Built-in statuses

These status names are recognized everywhere. An app’s status attribute can use any subset, relabel them, or add custom ones (see below).

A status with no explicit binding falls back to these defaults. When only the state is known, the default status is open, closed, or pending respectively.

Custom statuses on the status attribute

The status attribute is a select. Each option may set state: to bind a custom status name to a lifecycle state, and external: to map it to an external system value (see Attributes).

- name: status
  type: select
  label: Status
  visible: edit,conclude
  options:
    - name: open
      label: Open ticket
    - name: in_progress
      label: Waiting for input
      state: open
    - name: on_hold
      label: Waiting for a third party
    - name: closed
      label: Resolved        # no state: → defaults to the closed state

Resolution order for a status → state:

1. Built-in name (open, closed, pending) wins directly.
2. Otherwise the option’s own state: field.
3. If neither resolves, the state is left unchanged.

Zendesk mapping

Zendesk has six built-in ticket statuses. Conclude maps to them as follows.

Conclude → Zendesk:

Closing maps to solved, not closed, so the Zendesk ticket can still be reopened.

closed is terminal in Zendesk. Once a ticket reaches closed it cannot be reopened; a customer reply spawns a linked follow-up ticket instead. This is why Conclude maps a concluded activity to solved, leaving the reopen window (e.g. a customer reply within 30 days) intact.

Zendesk → Conclude:

An option’s external: value overrides both directions: if a status option sets external: solved, that option is used for the solved ↔ Conclude mapping instead of the defaults above.

external: override vs. the close event

Conclude pushes a status to Zendesk in two ways, and only one of them honors the external: override:

• Close/reopen events: concluding always sends solved, reopening always sends pending — both hard-coded, regardless of any external: value.
• Status-value sync (used when the status attribute changes): honors the option’s external: value, falling back to the table above.

These normally agree. They diverge only if a closed-state status option sets external: closed: the status-value path would send the terminal closed (no reopen window), while the close event still sends solved. Map a closed state to solved, not closed, unless you deliberately want tickets to become unreopenable.

Jira mapping

Jira workflows differ per project, so Conclude maps against Jira’s status category (To Do, In Progress, Done) rather than specific status names.

Jira → Conclude state:

Conclude → Jira: Conclude resolves a concrete Jira status by category for the issue type, using the project’s configured statuses:

Because the mapping is category-based, a project that renames its statuses (e.g. Backlog, Selected for Development, Shipped) still syncs correctly as long as each status keeps its standard category.

Typical Jira statuses

Conclude reads each status’s StatusCategory.Name, so the status names below are only examples — what matters is the category. Common statuses across Jira workflows, grouped by the category they normally carry:

Caveats — the list above mixes workflow templates, and category assignment is configurable per project:

• Open / Resolved / Reopened / Closed are the classic company-managed default workflow. Team-managed projects default instead to bare To Do / In Progress / Done (status name = category name).
• Selected for Development and In Review come from the Scrum/Kanban board templates, not the base workflow.
• Blocked is almost always a custom status (or a flag), not a built-in, and an admin may file it under To Do instead of In Progress. Either way it stays open in Conclude.
• Reopened is legacy — newer Jira workflows drop the dedicated status and reopen straight back to To Do / Open.

The only practical consequence for Conclude: any Done-category status (Resolved, Closed, Done, …) closes the activity; everything else keeps it open.

See also

• Attributes — the status attribute, option state: and external: fields.
• Connectors — Jira and Zendesk connector configuration.