Notify reporters when an issue’s status changes

When a tracked issue moves — say, into shipped — Atender sends reporters a status-update message in their linked conversations. Two default automation rules do this: Tell the reporter their report moved (email) and Tell the reporter their report moved (other channels). They send only when the reporter reads the new status differently from the old one, and you can edit, switch off or delete them like any other rule. You do not need to build a rule for the standard reporter notification. Deleting a status in the Issue Tracker settings moves its Issues to another status without a notice.

Use the An Issue’s status changes 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.

A rule on this trigger can also change the Issue’s status with the Change Issue status action — for example, to close a report automatically when the reporter goes quiet. See the chase-and-close recipe and the Actions catalogue.

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 Add rule, then Build it by hand instead. You can also type the rule, for example “Tell the reporter when an Issue is shipped”, click Build it, and check the result against the steps below.

3. Pick the trigger. Under When, choose An Issue’s status changes.

4. Add conditions to target the change you care about. The Only if section starts with no conditions, which fires the actions on every status change — click Add condition to get an empty condition. Fill that condition in:

   
   Field: Issue status
   Operator: is
   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, with the group set to Match all of these: - Field: Issue previous status - Operator: is - Value: In Progress

Type and 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 it simple. One set of conditions is enough if they already say everything you need. (If you want to notify on every status change with no filtering, skip step 4 and leave Only if empty.)

6. Add a reply step. Under Then, click Add step, choose Send auto-reply message, and write the message. Type / or click Insert field to add the issue fields.

Remember: the default rules already send the reporter status update when the reporter-facing status changes. A Send auto-reply message step on An Issue’s status changes then 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 name your team uses for the current status
• {{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 resolve only where the rule has an Issue: on an Issue trigger, or on a conversation trigger whose conversation is linked to an Issue (there, {{issue.previousStatus}} is not offered). 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. Click Create rule.

8. Turn it on. New rules start Off. Turn the switch beside the save button to On, then click Save changes.

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 fields resolve only where the rule has an Issue — an Issue trigger such as An Issue’s status changes, or a conversation linked to an Issue. If you copied this reply step 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
• Chase a quiet reporter, then close the report