Build an automation

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

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.

​

Diagnose unexpected behavior

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.