Recurring Requests documentation

Repeating a request, scheduling one, saving a template, and what an administrator controls.

Documentation for Mermaid Diagrams & Gantt Recurring Requests Issue Templates

Two of the three things this app does work as soon as it is installed. The third — repeating on a schedule — is switched off until an administrator turns it on for the project, so that nothing starts arriving in a queue because an app was installed.

If Repeat on a schedule is missing, that is why. See For administrators below.

In the customer portal, open a request you have already raised and choose Request again in the sidebar. The details are copied in and you can edit them before submitting.

Raise it now creates the request straight away. It is raised as you, so it appears in the queue exactly as it would if you had filled in the form yourself.

An attached form comes across in full, with its answers — including tables, choice questions and contact details. Fields holding several values at once are shown but not editable: they are copied exactly rather than rebuilt from text, because a list of selections cannot be typed reliably into a single box.

Choose Repeat on a schedule and fill in the form:

• Name it — how it appears in your list. Defaults to the request's summary.
• How often — once on a date, every day, every week, every month, or quarterly (every 3 months). Repeat every multiplies the day, week or month: every 2 weeks, every 6 months, and so on.
• On — for a monthly or quarterly schedule, which day of the month. The same day as the first one repeats the date you pick, as before. You can also choose a day of the month (1 to 31, or the last day), a weekday such as the first Monday or the last Friday, or a working day such as the second. Working days are Monday to Friday.
• For a weekly schedule, On can also be Chosen days of the week: tick the days, such as Monday and Thursday, and it repeats on them every week. This appears when your project's shortest gap between repeats is 3 days or less. When it does not, the form says why.
• First one on (Starting from with a pattern), and at — the date and time of the first request, which must be in the future. With a pattern, the first request is the first matching day on or after that date.
• Stop after this many — leave blank to keep going until the limit your administrator set.

See the dates before you save. Under the form, When it runs lists the next dates, up to five, in your time zone, and says when the schedule stops: after the number you set, or on your project's limit. If the form would be refused, for example because it repeats more often than your project allows, it says so there instead.

Days the service desk is closed. Your service desk can mark days as closed, such as public holidays. A request due on one goes out at the same time on the next open day, Monday to Friday, or is skipped, as the desk has chosen. The preview shows which, for example Mon 28 Dec 09:00 (25 Dec: the desk is closed).

Times are yours, not the server's. The app reads your timezone from your browser and shows it under the time picker. A schedule set for 09:00 stays at 09:00 after the clocks change, rather than drifting by an hour.

Monthly dates behave sensibly. A schedule anchored on the 31st falls back to the 28th in February and returns to the 31st in March — it does not stay stuck on the earlier day for the rest of the year.

A schedule that has been paused does not catch up. Resuming moves it to the next occurrence in the future. Six missed months do not arrive at once.

Schedules use no Automation steps. They run inside the app, not as Jira Automation flows. Flows of your own that run when a request is created still run, and count, as they would for a request typed by hand. What the same schedules would cost as flows from 3 December 2026 is in our guide to recurring tickets after step billing.

Not everything recurs on a cadence. Save as template stores the details of a request so you can raise the same one again later in a single click.

Nothing is created on its own. Raise it now on a template creates the request straight away, with the saved details, as you. Nothing is raised without your click, which is why templates are available by default and schedules are not.

Open My recurring requests from your user menu in the portal. Schedules and templates are on separate tabs.

• Pause stops a schedule without deleting it. Resume restarts it at the next future occurrence.
• Cancel deletes the schedule and its stored details.
• Each schedule shows how often it runs, naming any pattern (such as First Monday of every month), when the next request is due, how many have been raised, and the result of the last run. Edit opens the same form, with its dates preview.

A schedule that fails three times in a row pauses itself rather than retrying forever, and records why. The usual causes are a request type that was changed or removed, or an account that lost access to the project.

Go to Project settings → Apps → Recurring requests. In newer Jira Service Management navigation this is Space settings → Apps.

While recurring requests are off, the page shows Getting started. Turn on recurring requests turns scheduling on and leaves the limits as they are. When the shortest gap is more than 1 day, a second button, Turn on and allow weekday patterns (shortest gap 1 day), also sets the gap to 1 day, which repeats on chosen days of the week need, and changes nothing else. A 1-day gap also lets customers repeat a request every day, weekends included.

What customers can do

• Recurring requests — off by default. When on, customers can schedule their own repeats. Every request is created as the customer, arrives in your queues like any other, and counts towards your SLAs.
• Saved templates — on by default. Adds no unattended traffic, because a template raises a request only when the customer clicks Raise it now.

Limits

• Shortest gap between repeats — anything more frequent is refused. At 7, daily repeats are impossible. Above 28, monthly repeats are impossible too, because February is the shortest month and the check has to assume it. The gap is measured on the repeat the customer chooses: Monday and Thursday every week is a gap of 3 days, every working day a gap of 1, and a monthly pattern such as the first Monday is never closer than 28 days. Customers are offered chosen days of the week when the gap is 3 days or less.
• Stop every schedule after — each new schedule is given an end date this far ahead, so nothing keeps raising requests long after whoever set it up has forgotten. 0 removes the limit.
• Most schedules one customer may have — counts only active schedules in this project.
• Request types that may repeat — tick the ones you allow, or leave all unticked to allow everything.

Below the settings is every schedule in the project, with the person who created it, how often it runs (naming any pattern), when the next request is due and how many have been raised so far. Stop this schedule removes it.

In Project settings → Apps → Recurring requests, under Closed days, mark the days your service desk is closed, such as public holidays: click a date on the calendar to close it, and click it again to open it. Then choose Save settings. A project can keep up to 200 closed days, up to five years ahead. A closed day is removed a month after its date, the next time the closed days are changed and saved.

When a recurring request is due on a closed day

• Move to the next open day (the default) — it goes out on the next Monday to Friday that is not closed, at the same time. A run never moves earlier, and a move never adds one: if the next open day would reach the schedule's following run, that run is skipped instead. A request set up to run once always moves.
• Skip that run — nothing is raised for that date, and the schedule carries on from its next run.

Each schedule is checked against its own date, the one its customer sees, so a closed 25 December is 25 December wherever the customer is. A working-day pattern counts Monday to Friday with closed days included, so a run it picks on a closed day is moved or skipped like any other.

Saving moves the next run of any schedule that falls on a closed day, and brings back a run that was moved or skipped because of a day you open again, while that day is still ahead. Nothing is raised by saving. If some schedules cannot be updated at that moment, the page says so and offers Update next runs, and the app also updates them in the background shortly after.

A moved run can come closer to the next one than the shortest gap between repeats: a monthly run moved from 16 February to the 17th is 27 days before the next one. The shortest gap applies to the repeat the customer chooses, not to a single moved run.

Files. An attachment belongs to the request it was added to, and a scheduled repeat has nobody present to choose one. The app says so when the request you are copying has attachments. Add what you need after the new request is raised.

Fields that pick from a list of records. Some fields hold a reference to something else in Jira rather than text — Affected services is the common one. What the app captures is the name shown on screen, which is not enough to re-select the record, so the new request is created with that field blank and the app says which one it was. Everything else still carries across; one field that has to be chosen again is better than a repeat that never arrives. The exception is a field the request type requires: then a scheduled run cannot raise the request, it counts as a failed run, and three failed runs pause the schedule with the reason. Raise that request by hand, or ask an admin to make the field optional for the request type.

Who else is on the request. Participants and organisation sharing are not copied. The new request is raised by you alone; share it again once it exists.

More than one form. If a request has several forms, only the first form's answers are copied.

Anything the request type no longer has. If a field is removed from a request type after a schedule was created, that value is dropped rather than the whole request failing.

Scheduled requests are raised within a few minutes of the time you chose, not to the second. If you need something to exist before a particular deadline, set it for the morning rather than the minute.

Email [email protected] with the request key and the name of the schedule. First reply in 1-3 business days, depending on severity (see our service level agreement).