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. It opens on the Rules tab (the others are Manual Executions and Run History).

2. Start a new rule. Click New Rule in the top-right, then choose the Manual Builder card on the screen that opens.

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

4. Switch to conditional mode, then add conditions to target the transition you care about. The logic step starts on Always run, which fires the actions on every status change and takes no conditions at all — click Run when conditions match to get an IF branch with an empty condition in it. Fill that condition in:

   
   Field: issue.status
   Operator: equals
   Value: Shipped

The status values come from a dropdown populated with your tenant’s current Issue Tracker statuses. Pick from the list rather than typing: the builder shows the status labels your team recognizes, while the automation stores stable keys behind those labels so the condition keeps matching the selected status.

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 — both are dropdown fields, offering your tenant’s current type and priority lists rather than a fixed set — so you can, for example, only notify reporters when a bug ships, or only for high-priority issues. The rule stores the key behind the label you pick, so renaming a type or priority in settings doesn’t break a rule already built against it.

5. Keep the branch simple. One IF branch is enough if your conditions already say everything you need. (If you want to notify on every status change with no filtering, skip step 4 and leave Always run selected instead.)

6. Add a reply action. Click + Add Action, choose Send Auto-Reply Message, and write the message using the issue merge tags:

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

Available issue tags:

• {{issue.number}} — The number the reporter sees on their issue
• {{issue.title}} — The issue’s title
• {{issue.statusLabel}} — The current status label, best for customer-facing messages
• {{issue.status}} — The raw stable status key, best for automation or internal use
• {{issue.previousStatus}} — The status it moved from
• {{issue.type}} — The issue’s type key. Types are your tenant’s own vocabulary, editable in the Issue Tracker settings — bug and feature are only the defaults
• {{issue.priority}} — The team’s priority on the issue, as its raw key. Priorities are your tenant’s own vocabulary too, editable in the same settings — low, medium, high and critical are only the defaults

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 for the date range of your test — it filters by status and date only, so look for the rule by name in the Rule column.

• 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 dropdown labels map to stable stored keys, and a mistyped value never matches.

See also

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