Send Internal Newsletters
Using a workflow to send a newsletter is an unusual use case, but it's based on our actual working process at JetBrains. One of the software developers on the YouTrack team analyzes the processes for operational teams and writes workflows that support their business logic. These teams include our accountants, legal counsels, and travel coordinators, among others. These teams use YouTrack to organize their work and communicate with other employees in our organization. Sometimes, this developer is asked to modify these workflows in a way that alters their day-to-day routine. Before she updates their projects, she sends them a bulletin that explains how the change impacts their process.
The motivation for using YouTrack to deliver this information is based on the following factors:
All of the users who are affected by the changes are members groups that are assigned to the project team in YouTrack.
Every user has a registered email address stored in their user profile.
With workflows, YouTrack is capable of sending email messages.
This doesn't mean that you should use YouTrack to send newsletters to external users as a replacement for your email marketing platform, but it can be used as a tool for managing internal communication. YouTrack administrators and other users who apply changes to the application on a regular basis can use this technique to broadcast updates to other users whose work is impacted by these changes.
Create and Send a Newsletter
First, start with a dedicated project that contains a minimum number of fields. In this example, we use State and Recipients. Recipients is a
group -type field that stores multiple values. When the State becomes Sent, an email message that contains the issue summary and description is sent to every member of these groups.
The naive approach would be to send these emails using the
UserGroup.notify(subject, body) method. However, this solution is not optimal. People who belong to multiple groups in the list receive several identical messages. This example uses
notifications.sendMail(message, issue) and explicitly calculates the union of the groups in a list (meaning, a list of users that belong to at least one of these groups). With this approach, each recipient receives only one message. The newsletter author is the primary recipient and all others receive a carbon copy.
The first script in this scenario collects all of the users from these groups to build a single mailing list. The script is called
A second utility script contains a function that prepares the message to be sent. Its name is
Now, armed with these two little utilities, write a rule that sends an email message when the State changes to Sent:
Set up a Safety Net
It's best to be careful and write your workflows in a safe manner. Here are a few action rules that let you check your work before sending the newsletter. The first action rule helps you ensure that the email is sent to the right people:
The second action rule sends a copy of the message to the issue reporter so you can preview the content:
It's also possible to compose the newsletter in private and make sure other users don't see your work until it's published in the email. The following rule restricts the issue visibility to its reporter:
Here are some enhancements that you might consider:
Making new issues visible to a group of users who can collaborate on the newsletter.
Scheduling delivery based on the value that is stored in a field that stores the date and time.
Generating issues on a set schedule that include a template for content and a predefined send date if you deliver internal newsletters on a monthly or quarterly basis.