Notify reporters when an issue’s status changes

When a tracked issue moves — say, into shipped — Atender automatically sends reporters the default status-update message in their linked conversations. You do not need an automation rule for the standard reporter notification.

Use the Issue Status Changed trigger when you want something extra or custom: different wording, an internal ping, a webhook, a channel-specific follow-up, or a message that only goes out for certain transitions. The trigger fires once for every conversation linked to the issue, and each run carries issue-shaped tags for the number, title, status, type, and priority.

If three customers reported the same bug, each of their three conversations gets its own trigger run. 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:

• Atender already sends the default reporter update. When an issue moves to a status with a different reporter-facing label, reporters in linked conversations that aren’t archived get Atender’s built-in status-update message automatically. Add this automation only when you want an additional custom notification, internal workflow, webhook, or follow-up.
• 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 action runs in that reporter’s own channel context.
• 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.

Remember: Atender already sends the built-in reporter status update. A Send Auto-Reply Message action on Issue Status Changed creates a second reporter-facing message on top of that default update, so use it only when the extra message is intentional.

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

Available issue tags:

• {{issue.number}} — The number the reporter sees on their issue
• {{issue.title}} — The issue’s title
• {{issue.reporterStatusLabel}} — The current reporter-facing status label, best for customer-facing messages
• {{issue.statusLabel}} — The current internal status label
• {{issue.status}} — The raw stable status key, best for automation or internal logic
• {{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