Trigger-based automation rules that update task status, reassign work, write custom fields, and call webhooks — without writing a single line of code.
Every sprint contains dozens of micro-decisions that are obvious but time-consuming: move a task to "In Review" when a PR is opened, reassign it to QA when the developer marks it done, post a Slack message when the sprint closes. Individually each takes seconds. Collectively they steal hours per sprint from the people who should be building product instead.
Decuga Automations are evaluated server-side in real time — the moment a trigger fires, all matching rules execute within the same request. No polling, no delay.
Each automation rule has three parts: a trigger (what happened), optional conditions (extra filters), and one or more actions (what to do). All conditions are AND-combined — every condition must be true for the actions to execute.
Trigger
The event that starts evaluation — a task status change, a new task, an assignee update, or a sprint lifecycle event.
Conditions (optional)
Extra filters such as "status equals Done" or "assignee is set". All must pass for the rule to fire.
Actions
One or more things Decuga does automatically — update a field, reassign, call a webhook.
Decuga supports triggers across both task-level and sprint-level events, giving you coverage of the full delivery lifecycle.
| Trigger | When it fires | Config options |
|---|---|---|
| Task status changed | A task moves to a new status column | Target status (required), source status (optional) |
| Task created | A new task is added to the project | Sprint filter (optional) |
| Task assigned | A task's assignee field changes | Target user (optional, defaults to "any") |
| Sprint started | A sprint's status becomes Active | — |
| Sprint completed | A sprint is marked complete | — |
Actions are the "then do this" half of the rule. You can chain multiple actions on a single trigger — for example, change the status AND reassign in one rule.
| Action | What it does | Config |
|---|---|---|
| Set status | Updates the task's status | Choose any status defined in your project |
| Set assignee | Reassigns the task to a member | Pick from the project member list |
| Set custom field | Writes a value to a custom field | Field UUID + new value |
| Send webhook | HTTP POSTs a JSON payload to a URL | Target URL; payload includes full trigger context |
Add conditions to make rules precise. Condition fields include status, assignee, priority, or the UUID of any custom field you have defined. Available operators:
Here are four patterns teams set up in their first session with automations.
Auto-route to QA
Trigger: Task status changed → Done. Action: Set assignee to your QA lead. Every finished task lands in the right inbox without anyone touching it.
Sprint kickoff labelling
Trigger: Task created (in sprint X). Action: Set custom field "Source" = "Sprint planning". Lets you filter later to see which tasks were planned vs. added mid-sprint.
Slack release notes
Trigger: Sprint completed. Action: Send webhook to your Slack incoming-webhook URL. Decuga POSTs the sprint ID, project, and completion timestamp — your Slack app renders it as a release summary.
Auto-start in-progress
Trigger: Task assigned (any member). Condition: Status equals To Do. Action: Set status to In Progress. Tasks self-activate the moment someone picks them up.
Every rule execution — successful or failed — is recorded in the run log. Open any rule and click "View run history" to see a timestamped list of recent fires. Each entry shows the task or sprint that triggered the rule, whether the action succeeded, and the full error message if something went wrong. The run count badge on the rule card lets you see at a glance which rules are most active.
If a webhook action fails (network error, 4xx/5xx response), the run log captures the error message. Use this to debug and retrigger by temporarily toggling the rule off then on.
The webhook action sends an HTTP POST with a JSON body to any URL you specify. This makes it compatible with Zapier, Make (Integromat), n8n, Slack incoming webhooks, and any custom API. The payload structure depends on the trigger type.
| Trigger type | Payload fields |
|---|---|
| Task triggers | taskId, projectId, triggerType, status, previousStatus, assigneeUserId, priority, sprintId |
| Sprint triggers | sprintId, projectId, triggerType |
Webhook requests are sent asynchronously — they do not block the user-facing response. Decuga retries on transient network errors but does not guarantee delivery; use the run log to detect and reprocess failures.
Automations are available on the Pro plan and above. On Free and Starter plans the Automations tab is visible in the sidebar but shows an upgrade prompt. The number of rules you can create scales with your plan — Pro supports up to 25 active rules per project, Business and Enterprise have no limit.
Ready to try Decuga?
Start free — no account or credit card required. One month free trial of the Starter plan.
Start free trial