}
{caption && !thumbnail && {caption}{src && Select the image to view it full size.}}
;
};
An automation runs a configured sequence when something happens in your
workspace. Use it for a repeated step with a clear rule, such as responding to
a task changing status. You should be able to explain when it starts, what it
changes, and how to tell whether it worked.
**Before you begin:** Automations must be available to your workspace and
account. The feature can be gated by enabled features or beta access. If it is
absent from your sidebar, check with your administrator rather than assuming a
workflow already exists.
## Understand the parts
| Part | Purpose | Example |
| --------------------- | ------------------------------------------- | ------------------------------------------ |
| Trigger | The event that starts a run | Task status changed |
| Trigger configuration | Which events qualify | A particular From status and To status |
| Action | The work a step performs | Add task comment or Send notification |
| Condition | A branch or restriction inside the workflow | An If / Else step |
| Variable | A value from the trigger or an earlier step | The task that caused the run |
| Run | One execution of the workflow | The result of one qualifying status change |
Configure a narrow trigger before adding more actions. A workflow that reacts
to every update is harder to reason about than one that responds to a specific
transition your team already uses.
## Build a status-change workflow
This example uses an existing transition in your workspace, such as **In
progress → In review**. Those names are illustrative; choose your actual statuses.
1. Open **Automations** and create a workflow. Give it a name that explains the
outcome, such as **Mark work ready for review**.
2. Add the **Task status changed** trigger.
3. Set **From status** and **To status** to the transition you want, then save
the trigger configuration. Leaving a choice at **Any status** broadens the match.
4. Add **Add task comment**. Its configuration contains a **Comment** text area;
enter the message you want the workflow to add to the triggering task.
5. Write a useful comment, for example: “This task has entered review. Check the
description's acceptance criteria before completing it.”
6. Review the trigger and comment together. Confirm that the selected transition
is the one your team uses and the message makes sense for any matching task.
## Publish deliberately
Edits in the editor are draft changes. Use **Publish changes** when the
configuration is ready. Review any resource or destination details presented
before confirming publication. Publishing activates the version, so treat it
as a step that can cause configured work to run.
The workflow also has a **Draft / Live** control. A workflow must have a
published version before it can be turned live. After changing a published
workflow, check for unpublished changes rather than assuming the editor's
current configuration is already the version executing.
## Verify one run
Use a non-critical task and move it through the configured transition. Open the
workflow's **Runs** view to inspect what happened, then open the task itself.
For this example, confirm that the comment appears on the intended task.
Also try an update that should not match—for example, edit a description without
changing status. That should not behave like the configured status transition.
A test should demonstrate both when the workflow runs and when it stays idle.
Verification can create real comments, notifications, or other configured
changes. Choose test items and destinations you can review, particularly
when a workflow sends information outside Kato.
## Diagnose unexpected behavior
| Symptom | What to inspect |
| -------------------------- | ----------------------------------------------------------------------------------------- |
| Nothing runs | Check the published version, Live state, and exact trigger transition. |
| Too many runs | Look for Any status selections or other overly broad trigger settings. |
| The wrong item changes | Review the action's target and whether it uses the trigger's item. |
| An action fails | Open the run details, check the step configuration, and verify access to the destination. |
| Changes seem to be ignored | Check whether the editor has unpublished changes. |
If a workflow behaves unexpectedly, turn it off while you inspect its runs and
configuration. After correcting it, publish and verify the result again before
relying on it for everyday work.
## Related topics
- [Create your workspace](/documentation/create-your-workspace.md)
- [Changelog](/changelog.md)
- [Build a project pipeline](/recipes/project-pipeline.md)
- [Introduction](/documentation/introduction.md)
- [CLI configuration and CI](/documentation/cli-configuration.md)
: