Notification Rules

Notification rules email the person who raised an issue when the issue is created or updated. Use them to acknowledge a new request, or to tell a customer their issue has been resolved.

Create a notification rule

1. Open the Planner app and go to its Setup tab
2. Expand Automation Rules, then Automatic Issue Notification
3. Click Add a Notification Rule
4. Fill in the settings below and click Save

Setting	Description
Trigger	On Create sends when an issue is created. On Update sends whenever a matching issue is updated.
Issue Type	Required. The rule only applies to issues of this type.
Email Template	Required. The email template to send.
Integration	The email integration to send through. Leave it empty to use the environment's default.
Only When Received At	Send only for issues whose email arrived at one of these addresses.
Except When Received At	Never send for issues whose email arrived at one of these addresses. Issues that didn't arrive by email still get the notification.
Filter	An optional issue filter, in JSON. Only issues matching it get the notification.

The email always goes to the issue's requester, the person who raised it.

Received-at addresses

The two address lists let you treat inboxes differently, for example acknowledging mail to support@acme.com but not to vip@acme.com. Addresses are matched without regard to case. An entry can be an exact address or a pattern with one * before the @, such as *.support@acme.com.

An issue that didn't arrive by email never matches Only When Received At, and always passes Except When Received At.

Filter

The filter uses the same format as filtering issues through the API. For example, to send only for urgent issues:

{ "priority": { "eq": "URGENT" } }

Filters on related records, such as the requester's or assignee's own fields, aren't allowed, because rules run as the system rather than as a member.

Write the template

The template is rendered with three objects:

Object	Contains
issue	The issue, with camelCase keys: issue.title, issue.description, issue.number, issue.priority, issue.createdAt, issue.dueAt, and custom fields under issue.properties, such as issue.properties.order_id.
requested_by	The requester: requested_by.first_name, requested_by.last_name, requested_by.full_name, requested_by.email, requested_by.phone.
assignee	The assignee, with the same fields as requested_by. Empty when the issue is unassigned.

For example:

Hi {{requested_by.first_name}},

We've received your request "{{issue.title}}" (#{{issue.number}}).
{{#if assignee}}{{assignee.first_name}} is looking into it.{{/if}}

Status, group and issue type names aren't available in the template.

The sent email appears on the issue's activity.

How rules are applied

Every rule whose trigger, issue type, addresses and filter match sends its own email, so two matching rules send two emails.

• On Create rules run before trigger rules and automatic assignment, so they see the issue as it was created.
• On Update rules run after every update to a matching issue, including updates made by trigger rules and follow-ups. Test issues are skipped.

On Update sends on every update

An On Update rule doesn't check what changed. If you filter for a Resolved status, the requester is emailed when the issue is resolved, and again each time the resolved issue is updated, for example when a label is added. Pair the rule with a trigger rule that locks resolved issues, or filter on a field that only changes once.

Example: confirm new support requests

Setting	Value
Trigger	On Create
Issue Type	Support Request
Email Template	Request received
Only When Received At	support@acme.com

Every new Support Request that arrives at support@acme.com gets the Request received email straight away.