Privacy policy

Recurring Work Items for Jira — last updated 13 August 2026.

We do not receive your data

Recurring Work Items for Jira is an Atlassian Forge app. It runs entirely on Atlassian's own infrastructure, inside your Atlassian Cloud site. It has no servers of ours, no external database, and no network access to anywhere outside Atlassian — the app's manifest declares 0 external domains, which is why it carries the Runs on Atlassian badge. Nothing you enter into it, and nothing it reads from Jira, is ever transmitted to us or to any third party.

What the app stores, and where

To do its job the app keeps, in Atlassian-hosted app storage inside your own site:

• the recurrence rules you create — their schedules, and the issue templates you fill in;
• your project's working-day, holiday and permission settings;
• a history of each scheduled run, recording when it ran, what issue it created, and any warning or failure.

The only personal data in any of that is Atlassian account IDs — never a name, an email address, an avatar or anything else about a person. An account ID is kept in each of the 7 places where you have chosen somebody, and nowhere else:

• the rule's owner — whoever created it, so the rules table can say whose rule it is;
• a reporter in the issue template — the person each created issue is raised on behalf of;
• an assignee in the issue template — the person each created issue goes to;
• an assignee on any subtask in that template — the same, per subtask;
• a person picked in a user-picker custom field — whatever your own custom fields name, stored exactly as Jira gives it;
• whoever last saved a project's settings — recorded so the settings page can say when the settings last changed and by whom;
• the people a Named people permission lists — when a project restricts who may manage its rules to named people rather than to a role or a group.

A run history record holds none of them: it records what happened, not who. Nothing above is ever sent anywhere — it stays in Atlassian-hosted app storage inside your own site.

Three further things it writes into your Jira itself, not into app storage, so they belong to you and stay with your issues and projects:

• a label recurring-<rule id> on every issue it creates — the same label the rule editor tells you about, and the way to find everything one rule produced without the app;
• an issue property com.tiraisoft.jira-recurring.origin on every issue it creates, holding that rule's id and the date and time of the occurrence the issue is for — no names, no account IDs;
• a project property com.tiraisoft.jira-recurring.config on every project you enrol, recording that it is enrolled.

It reads project, issue-type, field, user and issue-status information from Jira as needed to present the rule editor and to create issues.

It also asks Jira to send a notification — POST /rest/api/3/issue/{key}/notify — when the daily health check first reports a rule as failing and when it first reports it working again. The notice carries the rule's name and the last failure Jira reported, names the recipient only by their Atlassian account ID, and is delivered by Jira to the rule's owner, or to that issue's assignee and reporter when no owner is recorded. Nothing about it leaves your site. See the troubleshooting page for how to stop receiving it.

Data residency

Because all storage is Atlassian's app storage, your data stays wherever your Atlassian site's data resides, and follows the same data-residency guarantees Atlassian gives the host product.

Retention and deletion

Rules and settings persist until you delete them. Run history records expire automatically 180 days after they are written. Uninstalling the app removes its stored data with the installation, per Atlassian's own app-data lifecycle.

An account that is closed is erased without anybody asking. Once a day the app reports every account ID it holds to Atlassian's own personal data reporting API and removes the ones Atlassian answers as closed — from the rule's owner, from a reporter or assignee in an issue template, from a subtask assignee, from a user-picker custom field, from the record of who last saved a project's settings, and from a Named people permission list. The rule keeps running: it carries a note saying which of its fields lost a person, so an issue that used to be assigned and is now created unassigned is not a silent change. A Named people permission that loses its last person falls back to project administrators only, so nobody is left able to schedule by accident.

What uninstalling does not remove is the three things written into your Jira — the labels and issue properties on the issues the app created, and the project property on each project you enrolled. They are in your site, not ours, so they outlive the app, and no part of them is personal data: a rule id, an occurrence date and an enrolment flag. The issues themselves stay too, which is the point of them. If you want the residue gone you can remove it yourself — the labels in Jira's own bulk-change, the properties through Jira's REST API — and nothing about the app is needed to do it.

Analytics

None. The app collects no telemetry and sends no usage data anywhere.

The assistant on this website

This documentation site — and only this site, not the app — has a chat panel that answers questions about the product. It is a feature of the website. It is not part of the Forge app, it has no connection to your Atlassian site, and nothing you type into it can reach, read or change your Jira data. Everything above about the app remains true whether you use it or not.

When you send a question, three things go to a third-party large-language-model provider, which routes it to the model that writes the answer: your question, the earlier questions and answers in that same conversation, and the text of the pages of this site. Nothing else — there is no account, no cookie and no identifier attached to it. The request is restricted to model providers that do not retain or train on what is sent to them. The category is the disclosure — Article 13(1)(e) GDPR asks for the recipients or categories of recipients — and neither the provider nor the model is named here.

• We keep no transcripts. The conversation lives in your own browser, in session storage, and is gone when you close the tab. Our server writes only the fact that a question was answered and how many tokens it cost — not the question, and not the answer.
• Your IP address is used to count requests against a per-minute limit, so that one visitor cannot exhaust the assistant for everyone. It goes no further: it is not written to our logs, not attached to the question, and never sent to the model.
• Do not paste anything confidential into it. It answers from published documentation, so it never needs your issue keys, your project data or any credential.
• It can be wrong. It is a language model reading these pages. The pages are the authority — every answer links to the one it came from.

The permissions the app asks for

Jira asks an administrator to consent to these at install. Each is listed with what stops working without it:

The app never asks anyone for a token, a password or any credential. All access to Jira goes through Forge's own authenticated bridge, using the scopes consented to at install.

Contact

support@tiraisoft.com. See Support.