Use automation instead of configuration to send notifications

[Jean-Francois Stenuit]

Currently, we have configured our organization to "automatically share email requests with the customer's organization. Requests sent from the portal will also be shared unless the customer selects otherwise".

Now, not all customers want to be "spammed" with notifications each time one of their colleagues opens a ticket. Some customers may even not be interested at all in the feature. Some others may be interested in only specific requests.

Is it possible to acheive similar, but more flexible results (i.e. notify a list of users from the organization uppon issue creation) using an automation ?

Like, uppon creation of ticket, if customer has subscribed to notifications, send mail to all users of this customer who opted-in to receive the notifications.

[Walter Buggenhout]

Hi @Jean-Francois Stenuit and welcome to the Community!

I am not sure if using automation is more flexible. While it does allow you to be more specific (there are multiple triggers you can use to send notifications and you have more control over the content of your email message using smart values), I would strongly recommend to first properly tweak your customer notifications. (one of the main reasons is that you have a limit to the number of automation rules you can run each month and using this for automating email requests may quickly add up, while there are other ways to do this).

In project settings > customer notifications you will first of all find that there are several events sending out notifications. You can enable / disable the events that trigger emails to reduce the amount of spam you refer to. It often helps to only enable the customer notifications for issue created / issue commented / issue resolved, so you only send emails when you absolutely need to inform your customer or are requesting a reply.

When you dive into the details of a notification, you will be able to specify who is being sent to (e.g. only the reporter of the ticket or everyone the ticket is shared with).

Hope this helps!

[Jean-Francois Stenuit]

Unfortunately, the type of notifications is done at project level, and not at company (group of users) level.

[Ste Wright]

Hi @Jean-Francois Stenuit 

How would you identify this list of users from within an Organization? There will need to be metadata for the rule to refer to (outside of just the Org, which would have the same result as the current issue).

---

Alternatively, you could...

1. Limit the emails back to just the reporter
2. Add key users to the "Request Participants" field by default, or even a group email address (which they would manage access to)

...and solve the problem that way. I think that would be simpler.

You might be able to use (2) with your option as well - turn off notifications, and use Automation to refer to that field's data.

---

Do you think the Request Participants idea is workable?

Ste

[Jean-Francois Stenuit]

Hi Stephen,

This is going in the right direction. Now I have set-up like this :

• custom field at the "Organization" level : WantNotifications (checkbox/boolean)
• custom field at the "User" level : ShouldBeNotified (checkbox/boolean)
• automation :
  • trigger : issue created
  • if organization.WantNotifications is true
  • then for each user in the organization
    • add user as watcher if user.ShouldBeNotified is true

Is it possible to access custom fields from {{ }} smart values ? Are there a smart values for organizations ?

And, above all, is there a "debug" mode to navigate through all the possible smart values ?