Out Of Office in Jira

September 29, 2022

Recently, one of my Clients asked, if it is possible to set up an autoresponder in Jira that works similarly to an autoresponder in e-mail clients, like MS Outlook. There are many amazing add-ons in the marketplace that implement such functionality. However, the client was interested in a configuration that did not require installation and payment for additional software. After collecting and briefly analyzing the business requirements, it seems that the vast majority of them can be implemented using the capabilities built into Jira itself.

Requirements

But let's start from the beginning. What were the client's requirements?

We would like to receive an Out-Of-Office e-mail notification whenever we assign a Jira task to the absent user.
We would like each user to be able to indicate when he won't be working and who will take care of his duties during his absence. The autoresponder message should include the coverer's name and e-mail address.
An additional requirement was that each user should be able to decide whether or not, apart from the e-mail notification, the task should be reassigned to the coverer.
The solution must work with Jira Cloud, require little to no maintenance and ideally not require programming skills by the maintenance team.
(*) The user should be able to configure autoresponder rules in each project independently, providing different dates and coverers. It should also be possible to add an autoresponder rule that works on specified dates on all unconfigured projects.
(*) The user should be able to create many rules independently by adding several different absences at the same time, e.g. if he wants to configure an autoresponder for the number of scheduled leaves.

There were other requirements, such as integrated automatic vacation planning or generating availability reports. These requirements, however, differ from the functionality of the autoresponder itself, so for the sake of clarity of this article, I will omit them here.

Due to the size of the article, I will divide it into two parts, each presenting a solution ready to be immediately applied to your instance. In the first article, the one you're reading right now, I will address all requirements except the last two (marked with an asterisk). I believe such a set of functionalities will be sufficient for many of you. In the next article, we will modify the solution to meet additional customer requirements.

Moving on to the solution. A short analysis shows that it will consist of two elements:

a database for storing autoresponder rules that will let users add new absences and related autoresponder configurations,
a mechanism responsible for sending e-mail notifications and reassigning tasks based on rules from the database.

Database

Let's start with the database. It can be created in many different ways. We will use a dedicated project in Jira. This project (let's call it Out Of Office) will store one type of request (Task) representing each of the employees in our organization. Tasks will be created by the HR department as part of the employee's onboarding process. Created tasks contain only the name of the employee in the Summary field and are assigned to the employees in the Assignee field. The other fields used in the project will not be visible on the issue creation screen. Each of the employees (except the HR department) will have access only to their tasks, thanks to which the appropriate level of privacy will be maintained. Employees will not be able to edit Tasks directly. For this purpose, a dedicated workflow transition will be configured, containing all the fields required by the autoresponder rule. That way, we will avoid a situation in which the user will alter the Summary (containing the employee's first and last name) or Assignee (giving the selected user permission to access the issue) fields.

So what fields will we use in the project?

Summary: this built-in field will contain the user's first and last name and will be set by HR staff during task creation,
Assignee: this built-in field will also be set during issue creation and will be used to assign the issue to the user to whom the rule applies. The user will not be able to change that field. Its purpose is to protect the visibility of the issue from other employees.
Start date: a built-in field representing the start of a planned user's absence
End date: a new custom Date picker representing the end of a planned absence
Coverer: a new custom User picker (single user) field representing the person replacing the user during his absence
Auto assign: a new radio button type custom field with On and Off (default) options. This field informs whether or not the issue should be reassigned to the coverer.
Info message: a new custom field of the Message Custom Field (for edit) type instructing the user what is the purpose of the individual fields. During field configuration, its recommended to create a dedicated context for the OOO project with the Default Value added as below:

{panel:bgColor=#deebff}

h4. On this screen, you can configure all your Out-Of-Office rule attributes.\\
----
- The *Start date* and *End date* fields indicate on which dates this Out-Of-Office configuration should be applied.
- Using the *Coverer* field you can optionally select the person who will take care of your tasks during your unavailability.
- By default, the system will send an OOO message informing about your absence to anyone who will assign you any tasks. If you also wish to reassign those tasks to Coverer please switch the *Auto assign* field to *On*.

{panel}

Regarding workflow configuration, it will be as simple as possible:

single status "To Do"
built-in "Create" transition with configured validator ensuring that user will fill in the Assignee field during the issue creation
"Configure OOO" loop transition is used to configure autoresponder attributes. We will add a screen to this transition with the following fields: Info message, Start date, End date, Coverer, Auto assign. We should also add two validators: one to ensure that the user will fill in the Start date and End date fields and another that checks if the End date is later than the Start date.

We will also need two more screens:

The Create Tasks screen containing only the Summary and Assignee fields
The screen for editing and viewing issues that include Summary, Assignee, Start date, End date, Coverer and Auto assign fields.

To limit the options in the Auto assign field only to On and Off (without the default option "none"), configure the Field Configuration to set this field as required.

We will also need a dedicated Permission Scheme. The atlassian-addons-project-access project role should be assigned to all available permissions. This is the default configuration that ensures that Jira Automation (acting as the above role member) will be able to perform all necessary actions. Additionally, we will also assign:

Project role (Administrators) representing HR department employees to Browse projects, Assign Issues, Create issues, Delete issues, Edit issues
Current assignee to Browse project, Transition issues
Application access (Any logged in user) to Assignable User

From now on, each user to whom we create a task on this project and assign it to him will be able to manage his autoresponder. Let's create 1-2 tasks for testing purposes.

Remember that we can do it only if we are added to the Administrators project role on this project!
As a user, after opening your task, we can configure the required parameters by clicking the "Configure OOO" button.

Note that if we are not employees of the HR department, and therefore we have not been added to the Administrators role, we should only see our request.

Automation rule

Let's move on to the second element of the solution - the mechanism responsible for sending e-mail notifications and reassigning issues. We will implement this element using Jira Automation. This rule must be configured as a global (working on all projects) or multiproject (working on selected projects) rule. If you are using a multiproject rule make sure you include the OOO project - only then the rule will be able to search for tasks in this project.

It is worth noting that in the Standard plan the number of global and multiproject automation rule executions is limited. Therefore, the described mechanism will work well among users of the Premium plan or it will require a more or less significant modification (more about it at the end of this article).

Automation consists of the following blocks:

Trigger: Issue assigned
Initial conditions: let's set up three conditions
- Issue fields condition: Project does not equal Out Of Office (OOO) - to disable running this rule during onboarding process when HR employee will create an initial rule for new user
- Issue fields condition: Assignee is not empty - to disable running this rule when someone will set assignee as Unassigned
- User condition: User who triggered the event (Initiator) is not Issue assignee - to disable running this rule when the user assigns himself during his unavailability. I suggest removing this condition during testing!
To retrieve the correct Out Of Office rule we will use the following set of components:
- Lookup issues action with configured JQL:
```
project = OOO AND assignee = {{issue.assignee}} AND "Start date" <= now() AND "End date" >= now() ORDER BY updated DESC
```
  to get the newest user OOO task (in case that HR employee will mistakenly configure duplicated issues in the OOO project)
- Advanced compare condition: {{lookupIssues.size}} does not equal 0 - to run the rule only if the user configured the OOO rule and set Start and End date to include the current date.
- Log action: Used rule: {{lookupIssues.first.key}} - to save this information in rule audit log for future troubleshooting purposes.
Main rule components are divided into 3 sections differentiated using if / else conditions:
1. Used in a case when the user did not configure his Coverer (left this field empty)
  - "If" block with Advanced compare condition: {{lookupIssues.first.Coverer}} equals Empty
  - Send email action: To Initiator with filled-in Subject and e-mail content (you can use smart values here to make it look more pleasant to end users) and set {{issue.assignee.displayName}} in From name field.
2. Used in a case when the user configured Coverer but left Auto assign in Off position:
  - "Else" block with Advanced compare conditions: {{lookupIssues.first.Coverer}} does not equal Empty and {{lookupIssues.first.Auto assign}} equals On
  - Send email action: To Initiator with filled-in Subject and e-mail content (different than previous because inside the message we are informing who is the Coverer) and set {{issue.assignee.displayName}} in From name field.
3. Used in a case when the user configured Coverer and set Auto assign to On to automatically reassign all issues to configured Coverer apart from sending autoresponder e-mail:
  - "Else" block with Advanced compare conditions: {{lookupIssues.first.Coverer}} does not equal Empty and {{lookupIssues.first.Auto assign}} equals On
  - Assign issue action configured to assign the issue to Smart value and setting the user as {{lookupIssues.first.Coverer}}
  - Comment on issue action to ensure that in the issue comment section we will find information that it was reassigned
  - Send email action: To Initiator with filled-in Subject and e-mail content (indicating who is a Coverer and that issue was reassigned to one) and set {{issue.assignee.displayName}} in From name field.

Working solution

The solution should now be fully functional. The user can configure his autoresponder rule. In his absence, when he is assigned to any issue, the configured rule will be applied. In the presented example, an e-mail will be sent to the user who assigned the issue and the request will be reassigned to the configured Coverer with an appropriate comment added.

What if we do not have the Premium plan

and the limit of global automation rules executions is insufficient? In this case, we will probably have to make some compromise between usability and possible solution costs. We have several options:

Let's start with the simplest solution, namely purchasing Jira Premium. It is worth considering this option because, in addition to the increased limit of the number of executable automation rules, we get many new functionalities, such as the possibility of archiving projects, access to Advanced Roadmap, access to an isolated sandbox environment to test and preview configuration changes, unlimited storage capacity, 24/7 Premium support and others ...
We can purchase a dedicated add-on from the marketplace. Such an add-on probably will have additional functionalities and its user interface can be more user-friendly. The purchase, however, will involve an additional cost. We should consider whether the additional cost is justified. Here you can find popular add-ons from the marketplace: https://marketplace.atlassian.com/search?hosting=cloud&query=out%20of%20office
We can write a script that implements the functionality of our automation rule using Adaptavist's Scriptrunner, without the limitations of Automation for Jira rule execution. This solution requires some Groovy scripting skills and knowledge of Jira Cloud REST API, plus the purchase of the Scriptrunner add-on itself. However, I encourage you to consider this option because thanks to this add-on, you can implement many different types of scripts that automate the work and integrate Jira with other systems.
We can configure Jira Automation for free by creating OOO rules independently on every single project. For example, we can create the OOO request type, add it to each project that requires OOO functionality and create a dedicated automation rule for each selected project. However, this solution is cumbersome to maintain and requires changes in the already implemented functionalities, e.g. excluding OOO issues from configured boards or reports.

If you have any questions about this setup, let me know in the comments.

Product Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

Get product advice from experts

Join a community group

Advance your career with learning paths

Earn badges and rewards

Connect and share ideas at events

Out Of Office in Jira

Requirements

Database

Automation rule

Working solution

What if we do not have the Premium plan

12 comments

Comment

Was this helpful?

Thanks!

About this author

TAGS

Community showcase

Atlassian Community Events