Configuration of e-mail templates and reminders

Overview of the template configuration
Editable / automated e-mails
Creating a new e-mail template
Drafting templates with variables!
Drafting templates with conditions!
Attaching rules to templates
Notification bells
Configuration of automatic reminders

Overview of the template configuration

All templates linked to your journal are stored in the templates configuration:

Existing templates are sorted:

First, by recipient. Each family of recipient gets a thumbnail, where all templates are stored for this family:

Second, by chronological order in the worflow process:
- starting with account creation
- following with peer review and decision events
- up until production

Note that editable and automatic e-mails are distinguished by the following icons:

Editable / automated e-mails

E-mails are the primary mean of communication through Nestor:

Authors and editors may not check the sytem regularly, and overlook their to-do list.
Referees may not have an active account, and by nature will take action only when prompted by e-mail

Consequently, understanding and properly configuring the mail engine will ensure your users are timely informed of their ongoing workload.

Actions & types of e-mails

When people work in Nestor, the system will detect important events and generate e-mails according to your configuration.

E-mails can be of two types:

Editable e-mails
Automated e-mails

Some events only generate editable e-mails, while others only generate automated e-mails. A few events can generate both types. In those rare cases, Nestor will guide you during the template creation:

Editable e-mails

Editable e-mails are triggered when a user wants to specifically get in touch with another user. Most common cases are:

the Editor-in-Chief assigns an associate editor
the associate editor invites a referee
the associate editor requests a revision to the authors

Several templates can be linked to the same event. In this case, the user will have to select which template is the most relevant for the situation:

After selecting the relevant template, the user has access to an editing box, where the template can be corrected before sending the mail:

Automated e-mails

Some specific events will trigger automatic e-mails. Most common cases are:

the author submits his revision > can trigger an automatic mail to the current editor
the referee declines the invitation to review > can trigger an automatic mail to the current editor
the article is published online > can trigger an automatic mail to the corresponding author, or a co-author

The following events are used by the system for account management. Please take caution when editing templates linked to these:

Name of the event	Description
USER_REGISTRATION	E-mail sent when an author creates his account
USER_REGISTRATION_ON_BEHALF	E-mail sent when the editorial office creates an account for someone else
USER_UPDATE_EMAIL	E-mail sent when a user updates his mail address (= login)
USER_CHANGE_PASSWORD	E-mail sent to a user requesting a password reset

Creating a new e-mail template

Creating an e-mail template is straightforward, just click here:

You will be prompted with the template creation form, where you first must select an event. It is very important to select the correct event, as the system will use your template only when this event is detected:

After selecting the event, Nestor will prefill the form with possible configurations to help you set up the template.

Drafting templates with variables!

Writing in progress... ↁ_ↁ

Any enquiries? please contact us: support@nestor-edp.org

Modifying date formats

Test variables

{% if article.articleType.code == 'LETTER' %}letter{% else %}paper{% endif %}

{% if articleEntity.finalDecision == 'CLOSED' %}

{% elseif articleEntity.finalDecision == 'WITHDRAWN' %}

Coauthor variables

{% if recipient.isPending %}

{% if recipient.hasValidated %}

{% if recipient.validOrcid %}

Drafting templates with conditions!

Nestor uses a programming language to generate text in messages. You can harness this and use branching conditions in your templates: https://twig.symfony.com/doc/2.x/tags/index.html. The configuration is a bit technical, but will result in:

modulable texts
cleaner interfaces
less technical support

The description below gives one typical example, but the possibilities are endless.

E-mail conditions: a case study

Let us consider the case of the acceptance letter, where we want to:

use some general text to inform the author that the article is accepted
IF certain conditions are met, modify a few parts of the text

For this purpose, we could create two different templates:

Template for a "regular article"

Template for a "note to the editor"

Dear author,

Congratulations on being accepted! We have received all source files and your paper is now in the hands of the copy editor.

You will receive the galley proofs in about two weeks.

Best regards,

The Editorial Office

Dear author,

Congratulations on being accepted! We have received all source files and your note to the editor is about to be published!

You will receive the galley proofs by tomorrow.

Best regards,

The Editorial Office

This presents the following downsides:

now we have two similar templates to maintain
this clutters the editor interface:

Instead, let us create one single template, inserting cool conditions when needed:

Global template

Dear author,

Congratulations on being accepted! We have received all source files and your {% if article.articleType.code == 'REGULAR' %}paper is now in the hands of the copy editor{% else %}note to the editor is about to be published!{% endif %}.

You will receive the galley proofs in about {% if article.articleType.code == 'REGULAR' %}two weeks{% else %}by tomorrow{% endif %}.

Best regards,
The Editorial Office

This results in a single template to maintain, and a cleaner editor interface:

Attaching rules to templates

In Nestor, critical actions will trigger a message and update the article status / dates when necessary. There are also cases when sending an e-mail should trigger an update of the article data, such as the section, or typically, a custom field.

E-mail rules: a case study

Let us consider this case, where a journal has a special procedure to highlight good papers on the journal website. For this purpose, the editorial office keeps track of the procedure, by using an article custom field:

We want the above field to be set automatically to "proposal sent" when sending this message :

Resulting automatically in:

To do so, the Editorial Office can configure an update rule in the template configuration:

After saving the configuration, each time this e-mail is sent, the "Highlight paper" value of the article will be set to "highlight proposed".

Notification bells

Important e-mails are sometimes lost in the crowd and overlooked by editors. This is especially true for e-mails outside of the workflow, dealing with particular cases etc. Notifications are here to prevent this! Nestor tracks e-mails tagged as "important" and highlights them in the recipient interface.

In the home page, editors will retrieve important e-mails they have received via the notifications menu:

In each article, they will retrieve them in the message history:

Setting up notification bells

Automatic notification bells

Nestor can tag an e-mail as "important" as soon as the mail is sent. To do so, the template must be configured accordingly:

In this example:

when the editorial office sends this message to an editor
then, this message will be tagged with a bell in the recipient editor interface (in the message history).

Manual notifications

Regardless of the template configuration, notification bells can be set up manually on specific e-mails, when needed.

Note that an editor can see and uncheck important mails if he/she is the recipient. He cannot vizualize/uncheck notification bells on other e-mails (to other users). For example below, connected as Phil Palaeon, checking the message history of article jeos20220021. We observe notification bells appear only if I am the recipient:

Profile right: access to all notifications

The right below allows the editorial office to have complete control over every user notifications in the journal:

First, this right unlocks a special view on all active notifications in the journal (regardless of the recipient)

Second in the message history, the Editorial Office can check/uncheck any mail deemed important (even when the EO is not recipient):

Configuration of automatic reminders

Automatic reminders are configured here, they are sorted by family of recipients:

Author and referee reminders

Author and referee reminders work similarly. Every morning after coffee, Nestor will check all articles submitted in the journal:

for each article, Nestor evaluates if an action is expected from the author or referees
if so --> Nestor checks the author/referee due date
it compares today's date with with the delay configured in the reminder
if the delay is met, Nestor triggers an automatic e-mail

Example 1 - Reminder for a revision

In my journal, one article is in revision: the author has a due date to revise (May 17)
The reminder configuration indicates: remind delayed author 3 days before due date
Nestor will send an e-mail to this author on May 14 (8am), reminding him to submit his revision

Example 2 - Reminder for a referee report

In my journal, one article is in peer review: the referee has a due date to send his report (June 12)
The reminder configuration indicates: remind delayed referees 1 day after due date
Nestor will send an e-mail to this referee on June 13 (8am), reminding him to upload his report

Editor reminders

Editor reminders work differently: editors usually work on several manuscripts at the same time, so it is not possible to send them one e-mail for each manuscript. Instead, Nestor will regularly send a summary of the editor to-do list, in this format:

Note that editor reminders are configured by profile: this way you can remind different profiles using different frequencies. Typically EIC do not need to be reminded as often as Associate Editors. In the screenshot below, we can observe that:

This reminder will send an e-mail only to Editors-in-Chief
On May 18
And then, every 7 days (May 25, June 1 etc.)

NB the template letter selection will propose all templates linked to the event EDITOR AUTOMATIC REMINDER. Make sure these templates include the variable {{ editorReminderList }}

If an editor complains about receiving too many automatic reminders, note that he/she can disable the reminders in his own account (check "configure e-mail alerts" in the editor guide).