Which git events are available as triggers?

Branch created, commit pushed, pull request opened, pull request merged, CI passed and CI failed. Plus release published if you work with releases.

Can I move a card to Done automatically?

Technically yes — a rule on "pull request merged" can move straight to the done column. Whether that is wise depends on your process: if a review sits in between, move to review and leave the last step to a person.

What happens if I downgrade the plan?

Existing rules keep firing. The plan governs whether you can create new ones and how many runs a month are included — it does not switch off rules you already have.

How many runs are included?

Private Plus 200 per month, Business Standard 1,000, Business Pro 25,000. Successful and failed runs count; skipped ones do not.

Why does the card not move on merge?

Two common reasons: the card key sat only in the branch name rather than the PR title, or the pull request was closed rather than merged — closing without merging deliberately fires nothing.

Move cards automatically with git

The previous tutorials connected git and the board. Now comes the part that saves time: rules that move cards from git, so nobody drags a card along by hand because the code merged an hour ago. Git triggers need the Developer plan; automations as a feature start at Private Plus.

What you need

The Developer plan for the git triggers — see pricing.
Git already wired up: linking commits and, for PR rules, the GitHub webhook.
A board with a working column and a review column.

1. Check the prerequisites

Without linked git events the rules have nothing to listen to. Set the hook up first — the rules build on it.

2. Build the rule: branch created → In progress

The most useful rule of the set, because it replaces the step everyone forgets:

When a branch is created,
then move the card to "In progress".

A branch event does read the branch name, so feature/zna164-sprint-picker is enough here — unlike a pull request.

3. Build the rule: pull request merged → Review

When a pull request is merged,
then move the card to "Review" and notify the assignee.

This one deserves a deliberate decision: moving straight to "Done" is tempting but skips the check. If a review is part of your process, leave the final step to a person.

4. Build the rule: build red → back and comment

When CI fails,
then move the card back to "In progress" and add a comment ("Build failed — please take a look").

The comment matters more than the move: it leaves a trace of why the card travelled backwards. A card that moves without explanation unsettles people more than it helps them.

5. Narrow with conditions

Without conditions a rule fires on every card of the board. Scope it to what belongs together: only cards in certain columns, only above a priority, only carrying a particular epic. Rules that run too often get switched off — and then the useful ones go with them.

6. Test and read the run history

Trigger each rule once for real: create a branch, merge a test PR, break a build on purpose. The run history then shows whether it fired. Three outcomes are possible — succeeded, failed, skipped. "Skipped" means a condition did not match, and does not count against your allowance.

Troubleshooting

Merging moves nothing. The card key sat only in the branch name rather than the PR title — or the PR was closed rather than merged.
The branch rule does not fire. No card key in the branch name, or the wrong prefix.
Cards bounce back and forth. Two rules are fighting — usually a backwards rule with no condition. Scope it to the destination column.
Allowance used up. Successful and failed runs count. Tidy up noisy rules or change plan.

Next steps

Set up board automations — the basics without git.
Show build status on the card.
Project management for developers.