Last updated: 19 August 2026.
Recurring Issues runs entirely on Atlassian's Forge platform. The app manifest declares no
external.fetch permissions, so the app cannot open a network connection to any
server outside Atlassian — your data never leaves Atlassian's infrastructure. We operate no
servers, no database and no analytics of our own.
storage:app — to save the recurrence rules you configure (which issue to
create, how often, and at what time) in Forge Storage.
write:jira-work — to create a Jira issue when a rule is due. This is the only
write the app performs.
read:jira-work — to ask Jira, at the moment you save a rule, whether you hold
the Create Issues permission in the project you named. The app uses it for nothing else.
The app reads no issue content: not your issues, comments, attachments, boards or projects.
Although read:jira-work covers a broad range of reads, the app makes exactly one
read call with it — Jira's mypermissions endpoint, about your own permission on
the project you name. The only other Jira context it receives is the key of the issue whose
panel you have open (for example PROJ-123), supplied by the Forge platform.
Everything else the app stores is text you type into the panel yourself, plus the
authorisation record described below.
The app does not request any user-identity scope. It reads no display names, email addresses or profile fields. It does store one Atlassian account ID per rule, as described under Where data is stored and processed.
Recurrence rules are stored in Forge Storage (the @forge/kvs
key-value store), which is hosted by Atlassian inside your site's Forge app storage. One
record is kept per issue, under the key rule:<issueKey>, plus a small index
of issue keys that have a rule.
Each record contains: the issue key, the summary, project key and issue type to use for new issues, the recurrence pattern (frequency, interval, days of week, day of month, week of month), the time of day in UTC, the timestamp of the next run, and an authorisation record — the Atlassian account ID of the person who saved the rule, the moment they saved it, and the project key their permission was checked against.
The account ID is stored solely as proof that the permission check ran, so that the daily trigger can confirm a rule was authorised before it creates anything. It is not shown to other users: the panel strips the authorisation record before a rule is sent to the browser.
All processing — evaluating which rules are due and creating the issues — happens in Forge functions running on Atlassian's infrastructure.
mypermissions endpoint, at the moment you
save a rule.A recurrence rule is kept until you delete it. Pressing Delete in the Recurring Issues panel removes that issue's rule and its index entry from Forge Storage immediately, and the app stops creating issues for it.
Once a week the app reports the account IDs it holds to Atlassian through the Personal Data Reporting API, which is Atlassian's own service. If Atlassian reports an account as closed, the app clears that account ID from every rule it stamped; those rules then stop creating issues until a current user saves them again. The timestamp and the project key of the original check are kept, so it stays visible that an authorisation check took place.
Uninstalling the app stops the scheduled trigger and removes the app's access to your site; the app's Forge Storage data is then removed by the Atlassian platform as part of its uninstall handling. Issues that were already created remain in Jira as normal Jira data and are not touched by uninstalling.
Questions, data requests or security reports: info@kyc-checks.nl.