Support & documentation
Help with AB Apps
Setup guides and FAQs for all three apps, plus a direct line to a real person. No ticket portal, no bots.
We aim to reply within two business days
Email us with your Atlassian site URL, the app name, and what you're seeing. We answer during EU business hours, typically much sooner than two days.
Team Reminders for JiraSet a reminder on any issue — for you, the assignee, or specific teammates.
What it does
Team Reminders adds a Reminders panel to Jira issues so a follow-up actually happens. Unlike a personal reminder, you can remind the current assignee or specific teammates — not just yourself — and the reminder is delivered as an issue comment that @-mentions each recipient, so Jira sends its own notification.
Getting started
- Open any Jira issue. Find the Reminders panel on the issue (it is also available as a "Reminders" context glance).
- Choose who to remind: yourself, the current assignee, or specific people (pick one or many with the user picker).
- Pick a date and a 24-hour time (HH:MM). The time is interpreted in your own Jira timezone.
- Optionally add a short message for context (up to 500 characters).
- Save. When the reminder is due, the app posts an issue comment that @-mentions each recipient.
Tracking and managing reminders
- The on-issue list shows every reminder set on the current issue with a status lozenge — scheduled, sent, or error — plus the target and message. Delete any reminder in one click.
- On a reminder that has already fired, use +1 day to snooze it by a day rather than recreating it.
- Open My Reminders (a global page) to see everything you've created across all issues, split into Upcoming and Past.
Frequently asked questions
How precise is delivery?
A scheduled check runs once an hour, so a reminder is delivered during the hour you chose rather than to the exact minute. For chasing follow-ups, deadlines, and approvals this is by design — we'd rather be upfront than over-promise minute-level precision.
Who is "the current assignee"?
It is resolved at the moment the reminder fires, so if the issue changes hands before then, the person assigned at that time is reminded. If the issue is unassigned when the reminder fires, it falls back to the reminder's creator.
Do the people I remind need to install anything?
No. Delivery is a normal Jira issue comment with an @-mention, so Jira handles the notification and email. Only the person creating reminders needs the app open.
Why 24-hour time?
To remove AM/PM ambiguity. Enter the time as HH:MM. Reminders set to a time in the past, or with an invalid date/time, are rejected.
Does it support recurring reminders?
Not currently — each reminder is one-time. You can snooze a fired reminder by +1 day. Recurring reminders may come in a future version.
Where is my data stored?
Only in Atlassian-hosted Forge storage inside your own Jira instance. The app makes no external network calls and sends nothing to us or any third party. See the Privacy Policy.
read:jira-work, write:jira-work, read:jira-user, storage:app — the minimum needed to read the issue, post the reminder comment, resolve recipients, and remember your reminders.Approval Chaser for JSMKeep pending Jira Service Management approvals moving — automatically.
What it does
Approval Chaser watches pending approvals in the Jira Service Management service projects you choose and posts a reminder comment that @-mentions the approvers who still need to act. If an approval keeps waiting, it can escalate to a named contact — with no automation rule for you to build or maintain.
Getting started
- Open the Approval Chaser configuration (a global page) and select the JSM service projects to watch.
- Set the nudge cadence in hours (default 24; minimum 1) — how long the app waits between nudges on the same approval.
- Optionally set Escalate after a number of days (default 3; set to 0 to never escalate) and choose an escalation contact.
- Optionally enable "Also post a customer-visible portal comment" to reach portal-only approvers by email (off by default).
- Save. An hourly scan then finds open requests with pending approvals and nudges the approvers.
Setting up a JSM approval (first use, or a quick test)
The app works from Jira Service Management's native approvals — the "Approval" panel JSM itself shows on a request. Moving a request into a status named "Pending for Approval" does not create an approval by itself; the workflow status needs an approval step attached:
- Go to Project settings → Workflows and edit the workflow used by your request type.
- Select the status that should require sign-off and choose Add approval. Set approvers to come from the Approvers user-picker field, with the number of approvals needed to pass (1 is fine for a test). Publish the workflow.
- Create a request of that type and set one or more users in its Approvers field.
- Transition the request into that status. JSM now shows its own Approval section on the issue — that pending approval is what the app reads and nudges.
The per-request glance
- Open any request. The Approval Chaser glance shows each pending approval with days waiting, the nudge count, and the last-nudge time (shown in UTC).
- Use Nudge now to send a reminder immediately, outside the normal cadence.
- If the request isn't a JSM request or has no pending approvals, the glance shows "No pending approvals on this request."
Frequently asked questions
How often will it nudge?
At most once per approval per cadence window. A newly created approval waits one full cadence window before its first nudge, so people aren't nudged the instant an approval appears. The scan is idempotent and catch-up-safe.
How does escalation work?
If Escalate after is greater than zero and an approval has been waiting at least that many days, the escalation contact is added to the mention (once) so the right person is looped in. Set it to 0 to disable escalation.
What is the customer-visible portal comment?
Optional and off by default. When enabled, in addition to the internal @-mention comment, a public portal comment is posted so portal-only approvers (who may not see internal comments) are reached by email.
Does it email approvers directly?
No. It posts comments; Atlassian / Jira Service Management generates the notifications. Licensed approvers get native notifications from the internal @-mention; portal-only approvers are reached via the optional public portal comment.
Is there a stability caveat I should know about?
Yes, in the interest of honesty: pending-approval data is read via Atlassian's JSM approvals API, which Atlassian currently designates as experimental and may change. We track Atlassian's changes and update the app, but this is worth knowing for a business-critical workflow.
Where is my data stored?
Only in Atlassian-hosted Forge storage inside your own instance — your project selection, cadence and escalation settings, and per-approval nudge timestamps. No external egress. See the Privacy Policy.
storage:app, read:jira-work, write:jira-work, read:jira-user, read:servicedesk-request, write:servicedesk-request — to find open requests, read pending approvals and approvers, post nudge/escalation comments (and the optional portal comment), and remember your configuration and nudge history.Recurring Work for JiraCreate Jira issues automatically, on a schedule you can check.
What it does
Recurring Work creates Jira issues from a saved template on a repeating schedule — daily, weekly or monthly, every N. Each schedule carries its own timezone, so a 09:00 schedule stays at 09:00 after the clocks change, and each schedule keeps a visible run history so you can see what fired and which issue it created. It runs on its own scheduled trigger, so it uses none of your Jira automation quota.
Getting started
- Open Recurring Work from the Jira Apps menu — either as a global page or from a single project's Project settings, where Jira shows it to project admins.
- Choose New schedule and give it a name. Pick the project and issue type. You only see the projects and issue types your own Jira permissions allow, and you need Create issues on the project you choose.
- Write the summary template (required) and optionally a description, assignee, priority, labels, and a due date N days after each occurrence.
- Set the recurrence: daily, weekly (pick the weekdays) or monthly (a day of the month, or the last day), with an every N interval — quarterly is simply monthly, every 3.
- Set the time as 24-hour HH:MM and choose the timezone for this schedule. Add a start date (required), and optionally an end date, a maximum number of runs, skip weekends, or create N days early.
- Use Preview next 3 runs to check the schedule does what you meant, then save. If the issue type requires a field the template cannot set, the save confirmation names the missing field(s), so you can fix the schedule before its first run.
Managing schedules
- Each row shows a status — Active, Disabled, Completed or Error — with the project and issue type, a plain-English recurrence summary, the next run, the last run and the issue it created.
- Expand a row for its run history: the last 20 runs, newest first, each marked automatic or manual and created or errored. History timestamps are shown in UTC; next run and last run are shown in the schedule's own timezone.
- Run now creates one real issue immediately as a test. It does not move the schedule forward, does not count toward the maximum number of runs, and never suppresses a future run.
- Enable / Disable pauses and resumes a schedule, Edit changes it, and Delete removes the schedule together with its run history. Re-enabling or editing recalculates the next run from now — there is no backfill of the paused period.
How recurrence and timezones work
Every schedule carries its own timezone, and the time you choose is treated as a wall-clock time in that zone before it is converted for scheduling. That means a 09:00 schedule still fires at 09:00 after a daylight-saving change, rather than drifting by an hour. The timezone list offers thirteen common zones plus your own Jira timezone, which is also the default for a new schedule.
The start date is itself an eligible occurrence. For monthly schedules, a day that does not exist in a given month is clamped to that month's last day — day 31 becomes 30 in April and 28 (or 29) in February; the occurrence is never skipped. There is no "first Monday"-style rule; monthly is day-of-month or last day.
Create N days early separates the two dates: the issue is created N days before the occurrence, but its date tokens and its due date still refer to the occurrence itself — useful for preparing a report ticket a couple of days ahead of the date it is about.
Template tokens
Tokens work in both the summary and the description. They are rendered from the occurrence date, in the schedule's timezone. Anything that is not a recognised token is left exactly as you typed it rather than being blanked out.
| Token | Renders as |
|---|---|
{{date}} | The occurrence date as YYYY-MM-DD — for example 2026-03-02 |
{{date+N}} | The occurrence date plus N days, as YYYY-MM-DD. {{date+7}} gives the following week. Whole, non-negative numbers only — there is no {{date-N}}. |
{{date:FMT}} | The occurrence date in a format you choose — {{date:dd LLL yyyy}} gives 02 Mar 2026 |
{{time}} | The schedule's time of day as HH:mm — for example 09:00 |
{{weekday}} | The weekday name — for example Monday |
{{month}} | The month name — for example March |
{{year}} | The four-digit year — for example 2026 |
{{week}} | The ISO week number — for example 10 |
A summary like Weekly status report — week {{week}} ({{date}}) produces Weekly status report — week 10 (2026-03-02). Month and weekday names are rendered in English, and a summary longer than 255 characters is trimmed to fit Jira's limit.
Frequently asked questions
How precise is the timing?
A scheduled scan runs once an hour, so an issue for a 09:00 occurrence is normally created during the 09:00 hour rather than at 09:00:00. Forge does not guarantee the exact moment a scheduled check runs, so if the platform delays one, the issue is created on the next check instead — the schedule never loses the occurrence. That is also why there are no hourly or minute-level frequencies: we would rather be upfront than over-promise precision we cannot deliver on the platform.
Who is shown as the reporter on the created issues?
The app creates issues as itself, so the app user is the reporter on every issue it creates — not the person who set up the schedule. You can still set an assignee on the template. The person configuring a schedule must hold Create issues on the target project.
What happens if a run fails?
The schedule does not move forward, so it retries on the next hourly scan, and the exact Jira error is stored and shown on the row. After three consecutive failures the schedule pauses — but visibly, with an error status, the error text, and a Retry button. Note that this surfacing is in the app only: there is no email or chat alert, so if a schedule matters, check the page. The most common cause is an issue type that requires a field the template cannot set.
What happens after downtime, or while a schedule is disabled?
By default missed occurrences are coalesced: after an outage you get one issue, not a flood. Turn on catch-up if you would rather the backlog be created one issue per hour until it is caught up. A disabled schedule creates nothing, and re-enabling it recalculates from now — it does not backfill.
Which fields can a template set?
Eight: project, issue type, summary, description, assignee, priority, labels, and a due date N days after the occurrence. Custom fields, components, parent/epic links, sprints, versions, attachments and sub-tasks are not supported. Descriptions are plain text — each line becomes a paragraph, with no markdown, tables, mentions or links. Sub-task issue types cannot be scheduled, because they cannot be created on their own.
How does "skip weekends" behave?
On a daily schedule a weekend occurrence steps forward until it lands on a weekday. On a monthly schedule it moves forward to the Monday, unless that would push it into the next month, in which case it falls back to the preceding Friday so the occurrence stays in its intended month. It has no effect on weekly schedules — if you select Saturday or Sunday there, issues are still created at the weekend. One edge case: a daily schedule with skip weekends and an interval that is a multiple of 7, starting on a Saturday or Sunday, can never land on a weekday, so it will show no next run. Change the interval or the start date. Weekends are the only non-working days recognised — there are no holiday calendars.
Can I use a cron expression, or repeat an existing issue?
No, by design. Recurrence is chosen from dropdowns — daily, weekly or monthly, every N, with day-of-month or last-day for monthly — precisely so nobody has to write or debug a cron string. There is no "first Monday of the month" option, no iCalendar rules, and no cloning of an existing issue; schedules always create from the template you save.
Who can manage schedules?
Creating, editing and Run now require Create issues on the target project, and every picker is filtered by your own Jira permissions. The Project settings view is shown by Jira only to that project's admins, so a team lead can manage their own project without a global administrator. To be straight about the current limit: the global page is available to every licensed Jira user, and disabling, deleting and Retry are not permission-checked there — any licensed user who opens that page can pause or permanently remove any schedule on the site, along with its run history. Treat schedule names as visible across the site, and if that matters for your instance, tell us at support@abapps.dev — it is the change we are most likely to make next.
Where is my data stored?
Only in Atlassian-hosted Forge storage inside your own Jira instance — your schedules and templates, and the last 20 run records per schedule. The only personal data stored is Atlassian account IDs (who created a schedule, and an optional assignee); no names or email addresses. The app makes no external network calls and sends nothing to us or any third party. See the Privacy Policy.
read:jira-work, write:jira-work, read:jira-user, storage:app — the minimum needed to list projects, issue types and priorities for the pickers, create the scheduled issue, read your own timezone and resolve an optional assignee, and remember your schedules and their run history.Still stuck?
Email support@abapps.dev with your Atlassian site URL, the app name, and a short description (a screenshot helps). We aim to reply within two business days, EU hours.