Blog · 1 October 2026

Jira: set the due date automatically, four ways that work

To set a due date automatically in Jira, create a Jira Automation rule with the Work item created trigger and an Edit work item fields action that fills Due date with a smart value such as {{now.plusBusinessDays(5).jiraDate}}. Every new work item in the project then gets a deadline five working days out without anyone typing it. That covers most teams. The rest of this guide covers the variations people usually want next: a deadline that depends on priority, one that follows the sprint, the time zone trap that shifts dates by a day, and work that repeats on a schedule and should arrive with its due date already set.

Statements about Jira Automation are as of October 2026, from Atlassian's own documentation. Atlassian now calls an issue a work item and a rule a flow. This guide uses both words, because most Jira admins still say rule.

The four ways at a glance #

The first three react to something a person did. The fourth creates the work and its deadline together, which is a different job, and it gets its own section below.

Method 1: set the due date when a work item is created #

Atlassian's trigger reference describes Work item created like this:

The flow will run when an work item is created. You can use this trigger with actions to customize the new work item, including populating fields, assigning to users, and adding sub-tasks.

The rule itself is five steps:

1. Open Project settings, then Automation, and create a rule.
2. Choose the Work item created trigger.
3. Add the Edit work item fields action and pick the Due date field.
4. Type a smart value into the field, for example {{now.plusDays(7).jiraDate}} for a week from creation.
5. Name the rule, turn it on, create a test work item and check the audit log.

End the smart value with .jiraDate. A due date field holds a date, and jiraDate is the format that returns one (1979-11-01 in Atlassian's own table). Without it the value carries a time and a zone, which is a likely reason when a rule "runs" and the field stays empty.

If the rule should only touch some work, add a condition before the action. An Issue fields condition on Issue type equals Bug keeps stories untouched, and a JQL condition such as duedate is EMPTY stops the rule from overwriting a date somebody set by hand while creating the item.

Count working days instead of calendar days #

Use plusBusinessDays when a deadline should skip weekends: {{now.plusBusinessDays(3).jiraDate}} lands three working days out. Atlassian's date reference defines the unit as Monday to Friday, 9am to 6pm. That definition names no public holidays and no other working week. A team that works Sunday to Thursday, or a deadline that falls on a national holiday, will still get a date on a day nobody is in. Two related values help at the edges: toBusinessDay returns the next working day when a date falls on a weekend, and toBusinessDayBackwards returns the previous one.

Method 2: a due date that depends on priority or type #

A single rule can give different deadlines to different work with If/else blocks:

1. Start with the same Work item created trigger.
2. Add an If/else block. In the first branch, use a condition such as Priority equals Highest.
3. Inside that branch, add Edit work item fields with {{now.plusBusinessDays(1).jiraDate}}.
4. Add an Else-if branch for High with {{now.plusBusinessDays(3).jiraDate}}.
5. Add a final Else with the default, for example ten working days.

Priority often changes after creation. If a work item is raised to Highest an hour later, the rule above never sees it. Add a second rule on the Field value changed trigger, watching Priority, with the same branches. The trigger reference says it supports "All system and custom fields", so the same pattern works for a custom Severity or Customer tier field.

Keep the numbers in one place. Two rules with the same table of deadlines drift the first time somebody edits one and forgets the other, so write the table in the rule descriptions and check both when either changes.

Method 3: set the due date to the end of the sprint #

Scrum teams usually want a work item due when its sprint ends, and to move when it moves to another sprint. Atlassian's automation knowledge base has an article for exactly this. The rule uses the Field value changed trigger on the Sprint field, set to trigger on value added, and an Edit work item fields action on Due date. The value it gives for a board with one active sprint is:

{{issue.Sprint.endDate.jiraDate}}

For boards with several active sprints, or when work carries over from completed sprints, the same article uses the latest sprint instead:

{{issue.sprint.last.endDate.jiraDate}}

Decide whether this should overwrite deadlines people set. A work item with a real external date (a contract, a launch) should not be moved to the sprint end just because it was planned into a sprint. A condition such as duedate is EMPTY, or a label that exempts it, keeps those dates safe.

The time zone trap #

Atlassian's reference says {{now}} "Returns the current date and time in UTC+00:00." Every example above builds on now, so every deadline is counted from the UTC date.

For a team far from UTC, that shifts deadlines by a day for part of every day. A work item created at 9am in Sydney is created on the previous day in UTC, so "due in 7 days" lands a day earlier than the person expected. A team in California sees the reverse late in the afternoon. The date reference offers convertToTimeZone for this: convert first, then add, then format, for example {{now.convertToTimeZone("Australia/Sydney").plusDays(7).jiraDate}}. Test it with work created near midnight in both zones before trusting it. Our Jira smart values guide covers this and two other date traps in more detail.

Method 4: recurring work that arrives with its due date #

Some deadlines belong to work nobody creates by hand: the monthly access review, the weekly report, the quarterly backup test. Here the question is how to get the ticket, with its date, every cycle.

In Jira Automation that is a Scheduled trigger plus a Create work item action, with the due date filled in the create step, for example {{now.plusBusinessDays(5).jiraDate}}. It works, and all of Method 1's rules apply: UTC dates, Monday to Friday, no holidays. Our Jira recurring tasks guide compares that approach with cloning and with scheduling apps, and Jira automation examples walks through building such rules.

Recurring Work Items for Jira is our app for this job. A rule is a schedule plus a work item template, and the due date is part of the template:

• Pick it from a list. The due date control offers The day it is created, 1 day after, 3 days after, 1 week after, 2 weeks after and 1 month after, or an expression you write yourself using the app's tokens, such as {{now.plusDays(10).date}}.
• Dates are read in the rule's own time zone, so a Sydney team's weekly review is dated by Sydney's calendar.
• The due date follows the project's working week. When a rule is set to move a run off a weekend or a holiday, the due date is moved the same way, using the working days and holiday list the project administrator set. A task due on a day the office is shut would be overdue before anyone could see it.
• A bad expression costs the date, never the work item. If a custom due date does not come out as a date Jira can read, the work item is still created, without a due date, and the run records a warning saying what came out and how to fix it.
• Subtasks inherit it. Each subtask a rule creates carries the parent's due date.

The app only dates work it creates on a schedule. It does not touch work items people create by hand, react to a priority change or follow a sprint. For those, Methods 1 to 3 are the right tools, and the two sit side by side in the same project without conflict.

When the manual way is enough #

Automation is not always worth it. Typing the date by hand is fine when:

• Deadlines come from outside Jira. A customer's date, a regulator's date, an event. No formula can guess them, and a rule that fills in a default can hide the fact that nobody asked.
• The project is small. A handful of new work items a week is quicker to date by hand than a rule is to maintain.
• Due dates are not used. If nobody filters, sorts or reports on the field, filling it automatically adds noise. Decide what the date is for first; our Jira reminder guide shows how teams actually act on due dates once they exist.

How to check it worked #

1. Create a test work item that matches the rule, or wait for one scheduled run.
2. Open it and confirm the due date is the day you expected, counting from your own calendar.
3. Open the rule's audit log and confirm the run shows success. A rule that ran but left the field empty usually has a value missing .jiraDate.
4. Try the edge cases once: a Friday afternoon for working days, a late evening for time zones, and a work item that already has a date if the rule has a duedate is EMPTY condition.

Common questions #

Can Jira set a due date without Automation? Jira Automation is the built-in way in Jira Cloud. Otherwise the field stays empty until an app or the person creating the work item fills it.

Can the due date skip holidays? Not with plusBusinessDays, which counts Monday to Friday. You would need a condition per holiday, or a tool that keeps a holiday calendar, such as our app for scheduled work.

Why is my due date one day off? Almost always the UTC trap above. Convert now to your time zone before adding days.