Workflows
Workflow statuses, templates, status↔agent bindings, and how tickets move through process states.
Workflows
A workflow defines the statuses a ticket can be in and the rules that move work forward — including when to launch agents or run automated tasks.
ArxDeck Helper can guide workflow setup through project chat — propose statuses, automations, bindings, and custom fields for you to review and approve before changes apply. See ArxDeck Helper.
Statuses
Each workflow has ordered statuses with:
- Display name and stable key (for automation matching)
- Initial status (exactly one per workflow)
- Terminal statuses (for example Done or Canceled)
- Optional flags such as requires user action for notifications
Tickets reference one workflow and one status within it at all times.
Global vs project-local
- Global workflows are reusable templates managed by platform superadmins. Projects use them when a content module that includes the workflow is installed and active.
- Project-local workflows belong to one project and are managed by that project's admins.
Project admins can duplicate a workflow within the same scope to iterate on a copy.
Default workflow
Projects can designate a default workflow for new tickets among workflows selectable in that project.
Seeded templates
New deployments typically include global templates such as Simple Todo (Backlog → Todo → In progress → In review → Done) and AI Coding (statuses tailored for agent handoff and human review). Projects install modules and set defaults explicitly — templates are not silently forced onto every project.
Status ↔ Agent bindings
The workflow editor includes Status ↔ Agent bindings — a managed layer that ties statuses to agents:
- One row per status + agent pair
- At most one agent per status; one agent may bind to multiple statuses
- Saving creates hidden automations for enter-status launches, comment-in-status launches, and mention handling
- See Workflow automations for trigger details including
preventDefaulton mentions
Automations
Workflow automations tie triggers (status entered, comment added, agent outcome, and more) to actions (run agent, run task, change status, merge pull request). See Workflow automations.
Multi-step pipelines use task templates — see Task templates & runs.
Custom fields
Each workflow owns its custom field definitions inline in the workflow editor (key, name, type, required, agent-writable, visibility). There is no separate global or project field catalog. Agents read and write fields via MCP where agentWritable is true.
Setup & configuration
Project admins configure workflows at Settings → Workflows. Superadmins manage global workflows under Platform → Workflows.
Typical setup steps:
- Install or create a workflow with the statuses your team needs.
- Set the project default workflow if desired.
- Add Status ↔ Agent bindings or raw automations for agent launches and status transitions.
- Define task templates for multi-step automated jobs.
- Define custom fields inline on the workflow editor when tickets need structured fields.
For complex changes, start a Helper chat and ask for a proposed workflow configuration, then approve proposals in the project inbox. Approved changes appear in History — see Configuration revision history.