Privacy policy

Applies to Working Days for Jira. Last updated: see Changelog.

The short version: this app receives the dates you configure into a rule, does arithmetic on them, and hands the answer straight back to Jira. It stores your calendars. It stores nothing else, and nothing leaves Atlassian.

What is stored

Working calendars, and only working calendars:

• the name you gave the calendar
• its time zone
• which weekdays your team works
• the dates you listed as non-working
• the optional note you added

That is the complete list.

Where it is stored

In Forge hosted storage, inside Atlassian's cloud infrastructure, scoped to your own site's installation of the app.

There is no database belonging to us. There is no server belonging to us. Your data never reaches one, because one does not exist.

What is never stored

• Work item summaries, descriptions, comments or attachments
• Custom field values
• User names, email addresses, account IDs or avatars
• Project or work item keys
• The dates that pass through a calculation

The last point is worth being precise about. When a rule runs, the app receives a start date and a number of working days, calculates an answer and returns it. Those values exist in memory for the length of one calculation and are never written down.

What is logged

One line per calculation, containing:

• which of the three operations ran
• whether it succeeded
• how long it took, in milliseconds
• if it failed, an error code such as WD-201 and its category

No dates. No calendar names. No work item content. No user identifiers. There is an automated test in the codebase that fails the build if one of our log lines can be made to carry any of those.

One honest exception. When a rule fails, the app throws an error so the rule stops, and that error's message is what the rule owner reads in the automation audit log. If the failure names something you configured — "Calendar 'Norway Support' no longer exists", for instance — then that name appears in the message, and Atlassian's own Forge logging records it alongside our own log lines. It stays inside your Atlassian tenancy and it is the only route by which anything you typed reaches a log. We would rather say so than let you discover it.

The consequence is real and worth stating: when you report a bug, we cannot look up what happened. We have to ask you. Troubleshooting lists what to include.

What is sent anywhere else

Nothing.

The app makes no outbound network requests. It has no external API, no analytics, no error-reporting service, no telemetry, no content delivery network, and no AI or machine-learning component of any kind. It runs entirely on Atlassian's infrastructure under the Runs on Atlassian programme.

What permissions the app holds

None.

The app requests zero Jira scopes. It cannot read your work items and it cannot write to them. When a rule sets a due date from this app's answer, it is Jira's own Edit work item step doing the writing, under your rule's own authority.

Encryption

Data is encrypted in transit and at rest by the Atlassian Forge platform, using Atlassian's own infrastructure and key management.

Data retention and deletion

Calendars persist until you delete them or uninstall the app.

Uninstalling the app deletes every calendar it stored for your site. This is automatic. A later reinstall starts empty.

To delete a single calendar, use Settings → Apps → Working Days.

Sub-processors

None. No third party processes any of your data, because no data reaches any third party.

GDPR

For calendar configuration, you are the data controller and Atlassian is the processor of record — the data sits in your Atlassian tenancy under your agreement with Atlassian. We hold no copy.

The app stores no personal data. A calendar name is text you chose; if you put someone's name in it, that is the only route by which personal data could enter, and you can edit or delete it at any time.

Changes

Material changes to this policy will be listed in the Changelog.

Contact

Questions: maxim@gordienok.com