Notify reporters when an issue’s status changes

When a tracked issue moves — say, into shipped — nothing tells the people who reported it unless you tell them yourself. The Issue Status Changed trigger gives you an automation rule that does exactly that: it fires once for every conversation linked to the issue, and each one gets its own reply, in its own channel, worded with tags that name the issue by number, title, status, type, and priority.

If three customers reported the same bug, each of their three conversations gets a separate reply. There’s no batching and no separate “notify reporter” action to configure — this is an ordinary automation rule using a trigger and tags that happen to be issue-shaped.

Before you start

• Admin permissions to edit automation rules
• At least one issue with a reporter linked to a conversation
• A read of What are Automations? if you’re new to the builder

How the trigger behaves

A few things are worth knowing before you build the rule:

• The trigger only fires on an actual status change. Saving an issue without changing its status doesn’t fire it.
• It fires once per linked conversation, not once per issue. The automation engine’s subject is a conversation, so if an issue has multiple reporters, the rule runs separately for each of their conversations — each reply goes out on that reporter’s own channel.
• The issue fields ride along as context. Every run carries the issue’s number, title, current status, previous status, type, and priority, so your conditions and your reply text can both use them.

Steps

1. Open the rules page. Go to Settings → Automation Rules. The page opens on the Manual Builder tab.

2. Start a new rule. Click New rule in the top-right.

3. Pick the trigger. Choose Issue Status Changed from the trigger list.

4. Add conditions to target the transition you care about. Add a condition:

   
   Field: issue.status
   Operator: equals
   Value: Shipped

The status, type, and priority values come from a dropdown — pick from the list rather than typing, since the underlying values are fixed vocabulary and a typed value that doesn’t match exactly won’t match at all.

You can narrow further. To notify only when an issue moved out of “in progress” specifically (rather than, say, straight from “backlog”), add a second condition joined with AND: - Field: issue.previousStatus - Operator: equals - Value: In Progress

issue.type and issue.priority are available the same way, so you can, for example, only notify reporters when a bug ships, or only for high-priority issues.

5. Add a branch. Leave the default Always branch if your conditions already say everything you need.

6. Add a reply action. Click Add action → Reply, and write the message using the issue merge tags:

Good news — issue #{{issue.number}} ("{{issue.title}}") is now {{issue.status}}.

Available issue tags:

• {{issue.number}} — The number the reporter sees on their issue
• {{issue.title}} — The issue’s title
• {{issue.status}} — The status it just moved to
• {{issue.previousStatus}} — The status it moved from
• {{issue.type}} — bug or feature
• {{issue.priority}} — The team’s priority on the issue

These tags only resolve on an issue trigger. Used anywhere else — or alongside {{comment.*}} tags, which are equally blank on this trigger — they’ll simply render empty rather than leaving the raw tag in the text, so double-check your wording if you’re reusing a template across triggers.

7. Name and save. Something like “Notify reporter: issue shipped” is clear enough for the run history later.

8. Enable it. Toggle the rule On.

Verify it worked

Move a test issue that has a linked conversation into the status your condition checks for (e.g., Shipped). Open the linked conversation — the reply should land there worded with the real issue number, title, and status.

If the issue has more than one reporter, check each linked conversation. You should see the same reply text, personalized only by which conversation it landed in, once per reporter.

Troubleshooting

• Symptom: Rule didn’t fire at all. Fix: Confirm the status actually changed — resaving an issue at the same status doesn’t trigger the rule. Then confirm the rule is enabled, and check Run History filtered by the rule and the date range of your test.

• Symptom: Rule fired for one reporter’s conversation but not another’s. Fix: The trigger fires once per conversation linked to the issue. If a reporter’s conversation isn’t linked to the issue, it won’t get a run. Check the issue’s linked conversations.

• Symptom: The reply went out but the tags didn’t fill in. Fix: Issue tags only resolve on the Issue Status Changed trigger. If you copied this reply action into a rule built on a different trigger, the tags will render blank instead of throwing an error.

• Symptom: Condition never matches even though the issue clearly moved to that status. Fix: Use the dropdown to set issue.status / issue.previousStatus / issue.type / issue.priority rather than typing a value by hand — the stored values are lowercase and exact, and a mistyped value never matches.

See also

• What are Automations?
• Create your first automation
• Trigger types reference