Privacy policy

Last updated 25 September 2026

This policy explains what data Eriksen Labs handles, and what it does not. It covers our Atlassian Marketplace apps, what it does, and this website.

Eriksen ENK, trading as Eriksen Labs, registered in Norway under organisation number 937 027 834. We are the data controller for the limited processing described below.

Contact: support@eriksenlabs.com

The app collects no data and transmits nothing to us. This is a design decision, not a policy promise, and it can be verified:

• The app requests no Atlassian permission scopes. You can confirm this on the install screen — it has no access to your Confluence content, users, or spaces.
• Diagrams are rendered entirely in your browser. Diagram text is never sent anywhere for processing.
• Your diagram content is stored by Atlassian as part of the Confluence page it lives on. We never receive, store, or have access to it.
• We operate no servers that receive app data. There is no backend to breach.
• The app sets no cookies and contains no analytics, tracking, or third-party scripts.

Atlassian's handling of your Confluence content is governed by Atlassian's privacy policy.

This app does store personal data, inside your own Atlassian instance. We say so plainly because the alternative — a blanket claim that none of our apps store anything — would be untrue.

What it stores, and why:

• The Atlassian account ID of the customer who creates a schedule or a template. A scheduled request has to be raised as the person who asked for it rather than as the app, which is only possible if the app remembers who they are.
• The details of the request being repeated — its field values and the answers of any attached form. Those answers are whatever the customer typed, which often includes names, phone numbers and email addresses. They are kept so the repeated request can reproduce the original.

All of it lives in Forge storage, which is Atlassian's own infrastructure, scoped to your installation. Eriksen Labs cannot read it. We operate no servers that receive it and have no mechanism to retrieve it. It is not transmitted anywhere outside Atlassian.

How long it is kept. A schedule's details are stored until the customer cancels it or an admin stops it; a template's until the customer deletes it. The app reports the account IDs it holds to Atlassian each week and erases everything associated with an account once Atlassian reports that account closed.

Uninstalling the app does not remove it at once. Atlassian keeps an uninstalled app's Forge storage for 28 days and then deletes it, as it does for every Forge app. We cannot read it during that time, and reinstalling the app starts it empty rather than restoring it.

An admin can see and stop every schedule in their own project, and a customer can see, pause and cancel their own from the portal at any time.

This app records nothing about the people who use it: no account ids, and not who saved, changed, restored, deleted or used a template. It keeps the templates your administrators make, and numbers. A template holds personal data only if someone puts it there.

What it stores, and why:

• Templates: each template's name, the projects and issue types it is for, and the summary, description, checklist, labels and priority it fills in. This is text your administrators write or copy from an issue, so it holds whatever they put in it. When a template is saved from an existing issue, the app removes @mentions, attachments, content from other apps, links to people's profiles, mailto links and email addresses from the description before it is kept. Other text is kept as written, so a name or phone number typed in the description stays. The template's name starts as the issue's summary, and labels are copied as they are.
• Dated versions: a copy of the template each time a change to it is saved, with the date and time and which parts changed, so a change can be undone. Who saved it is not recorded.
• Deleted templates: a copy of each deleted template, so it can be restored.
• Usage counts: how many times each template filled in its summary or description in Jira's Create dialog by itself, how many times someone created at least one issue from it in a Create dialog opened from the template gallery (a project's Templates page, or the app's page under Apps), and when it was last used. Counts and a time, never who.
• Daily check results and settings: the problems the last check found, a list of recent checks that found problems, when the notice about them was last dismissed, and whether alert issues are on and which project and issue type they go to. These hold template, project and issue type names, not people.

All of it lives in Forge storage, which is Atlassian's own infrastructure, scoped to your installation. Where your Jira site's data is pinned to a data residency location, Atlassian keeps Forge storage in that location too. Eriksen Labs cannot read it. We operate no servers that receive it and have no mechanism to retrieve it. The app sends nothing outside Atlassian: it declares no external addresses, so there is nowhere for data to go, including to us.

If something fails, the app writes a short error line to its Forge logs, which Atlassian keeps and we can read to fix the problem. When a change in Jira's Create dialog fails, the line holds only the kinds of error and the ids of the fields involved, never Jira's message text. The other lines say which step failed: recording a template's version history, the daily check, or clearing expired deleted templates, followed by the error's own message, cut short. The app writes no account ids and nothing from the Create dialog form to its logs.

Two things are kept in Jira itself rather than in app storage. Default templates are copied into Jira's Create dialog settings for each project that uses them, because that is how Jira hands them to the dialog. And if an administrator turns on alert issues, the app creates ordinary Jira issues in the project they chose, naming the templates, projects and issue types that stopped working.

What people type in Jira's Create dialog is read in their own browser, only to decide whether the app may fill a field and which note to show. The app does not store it or send it anywhere.

When someone picks a template in the template gallery, the app puts that template's summary and description text, and the time, in the browser's session storage for that tab, so that the app leaves the picked template alone in the Create dialog. The app removes it when that dialog closes, and the browser removes it when the tab is closed. Otherwise the app ignores it after two hours. It holds nothing about the person.

How long it is kept. A template is kept until an administrator deletes it. The last 50 versions of each template are kept, and older ones are removed. A deleted template can be restored for 30 days; after that it is removed with its versions and usage counts, the next time the daily check runs or an administrator opens the app's settings. The daily check keeps the results of its last 20 checks that found a problem. Jira's Create dialog settings are rewritten whenever a template changes, and removed for a project that no longer has a default. Alert issues are yours and stay until you delete them.

The app has no uninstall step of its own. What happens to its Forge storage, and to the Create dialog settings it kept in Jira, when it is uninstalled is handled by Atlassian's platform rather than by the app.

The scanner makes no network requests at all. It reads your code on your own machine and writes a single HTML file beside it. There is no account, no telemetry, no usage reporting and no update check. You can disconnect from the network and it works unchanged — which is the honest way to verify this claim, and better than taking our word for it.

The pull request check runs inside your own CI runner. Your source code is read there and is not sent to us. The Action uses network access to obtain its runtime and dependencies and to interact with the GitHub workflow and repository. No repository name, file, finding or identity is sent to Eriksen Labs.

Because none of your content reaches us, we hold no personal data from your use of this product and there is nothing for us to lose, sell or be compelled to hand over.

This site is static and sets no cookies. It is hosted on Cloudflare Pages. Cloudflare processes technical information such as IP addresses in server logs to deliver the site and protect against abuse, acting as our processor.

Page views and load times. We use Cloudflare Web Analytics to see which pages are read and how quickly they load. Each page loads a small script from Cloudflare. When the page has loaded, and again when you leave it, the script sends Cloudflare the page's address, the address of the page that linked to it, details of your browser and operating system, and timings for how the page loaded, including which parts were slowest. Like any request, it reaches Cloudflare with your IP address. We see only totals, broken down by page, referring site, country, browser, operating system and device type.

The script sets no cookies and uses no local storage. Cloudflare states that it does not use this data to fingerprint visitors or to track them across websites, and that it does not log the query part of page addresses. Cloudflare keeps the complete data for 7 days and a sample of about 10% after that; its dashboard shows us up to six months. Cloudflare processes this data on our behalf. Content blockers often block the script, and the site works the same without it.

The legal basis is our legitimate interest in knowing which pages are useful and keeping the site fast.

If you email us, we receive your address and whatever you choose to include. Our mail is hosted by Zoho, acting as our processor. We use support correspondence only to answer your question, and keep it for up to 24 months so we can follow up on recurring issues. We do not use it for marketing, and we do not sell or share it.

If you raise a request through our support portal, we receive your name, email address and whatever you include in the request. The portal is provided through Atlassian Jira Service Management. Requests are used and retained on the same terms as support received by email.

The legal basis is our legitimate interest in providing support for software you use.

Under the GDPR you can ask us to give you a copy of your data, correct it, delete it, restrict how we use it, or object to our use of it.

Support correspondence is the only personal data Eriksen Labs itself holds. Email support@eriksenlabs.com and we will respond within 30 days.

Data held by an app inside your Atlassian instance — such as the schedules and request details stored by Recurring Requests — is a different matter, because we have no access to it. A customer can delete their own schedules and templates from the portal, and a site admin can stop any schedule. Uninstalling the app removes the rest, but not at once: Atlassian keeps it for 28 days first. In Issue Templates, an administrator can edit or delete a template. Its earlier versions keep the old text until 50 newer versions have been saved, or until 30 days after the template is deleted. If you need something erased and cannot reach it yourself, ask your site administrator; write to us as well and we will explain exactly what the app stores and where.

If you are unhappy with our response you can complain to the Norwegian Data Protection Authority (Datatilsynet).

Where one of our apps processes personal data on behalf of an Atlassian customer, that customer is the controller and we are the processor. The terms governing it, including sub-processors, breach notification and deletion, are in our Data Processing Addendum.

If this policy changes we will update the date at the top. Material changes affecting app behaviour will also be noted in the app's release notes on the Atlassian Marketplace.