Data & privacy
Last updated: 5 September 2026
This page says what OnTask stores, where, for how long, who can see it and how it is deleted. Every number on it is one the code enforces. The policy that governs the relationship is the Privacy Policy; the technical statement is the Security & Sub-processor Statement; the contract for customers who need one is the Data Processing Agreement.
Where the app runs
OnTask is a Forge app. Its code runs on Atlassian's infrastructure and its data lives in Forge hosted storage on your own Atlassian site. Nothing runs on servers Soverain operates, because there are none.
No external network access
The app's manifest declares no external permission and no remote host. It cannot reach anything outside Atlassian: no analytics service, no error tracker, no AI provider, no content delivery network. Even the typefaces are bundled with the app rather than requested from a font service, so the running page makes no request to anyone but Atlassian. Atlassian confirms Runs on Atlassian eligibility on every deployment.
There is no model in the product. Ranking is a deterministic score computed on your site — see How the ranking works.
Permissions the app asks for
| Scope | Why |
|---|---|
read:jira-work | Your assigned issues and their comments and worklogs; the permission check before a manual entry |
write:jira-work | The worklog and the optional comment you confirm on the stop screen — nothing else, and never in the background |
read:jira-user | Your profile's timezone; and whether an account still exists, for automatic erasure |
storage:app | The running clock, your history, preferences and drafts |
report:personal-data | Atlassian's Personal Data Reporting API, described below |
Every call to Jira that reads or writes on your behalf is made as you, with your permissions. OnTask cannot see an issue you cannot see, and a worklog it writes is authored by you.
What OnTask stores
| Data | What it contains | Kept for |
|---|---|---|
| The running clock | The issue key and summary, when it started, how long it has been paused | Until you stop or discard it |
| Session history | For each logged session: the issue key, the duration, and the summary you typed | 12 months |
| Submission record | The record that stops one confirmation producing two worklogs: your account ID, the issue, the duration, the worklog's id | 30 days |
| An unsent draft | A summary you started typing and did not log | 7 days |
| Your preferences | The comment default, the daily-total threshold, your six ranking sliders | Until you delete your data |
| Site setting | Whether comments are allowed site-wide — not personal data | Until deleted |
| Reporting bookkeeping | When each account was last reported to Atlassian, and which are queued for erasure | Until deleted |
The personal data here is your Atlassian account ID and the summaries you wrote about your own work. The summaries are the part worth taking seriously: they are a per-person, timestamped record of what you worked on, in your own words. They are stored so the Today list can show them and so your history survives a reload; nobody else sees them.
A month of session history is capped at 400 entries, so it cannot grow without bound.
A daily job enforces the retention periods above. It can read Jira — to ask whether an account still exists — but it is structurally unable to write to Jira.
What it does not store
- No display names, and no other profile data. Every name OnTask shows — the person who mentioned you, who a comment will notify, your greeting — is looked up for that response and discarded. Nothing persisted holds a copy of anyone's profile.
- Nothing about anyone but you. There is no team view, no manager report and no aggregate. One person's OnTask data is never shown to another person by this app. That is a product decision, not a gap: the moment a time tool can show someone else's hours it becomes a surveillance tool and the data stops being honest.
- No analytics, no telemetry. Log lines carry counts and durations only — never a storage key, a stored value, an account ID or a raw error.
What it writes into Jira
Two things, both authored by you and both shown to you before they happen: a worklog — duration, start time, and your summary as its comment if you leave that switch on — and, only when you tick it, an issue comment containing your summary exactly as typed, plus the duration and the issue key. See The clock & worklogs.
Those become ordinary Jira data. They are yours, they live in Jira's own history, and — this matters for the next section — deleting your OnTask data does not delete them.
Personal Data Reporting
Because OnTask stores account IDs, it implements Atlassian's Personal Data Reporting API.
Once a week, OnTask reports every account ID it currently holds to Atlassian. Atlassian answers with the accounts that have since been closed, and a daily job erases those people's data. An erasure that fails stays queued and is retried; it is never silently dropped. Accounts whose data has already gone are dropped from the bookkeeping — keeping the ID would mean holding personal data about someone whose data was already erased.
Atlassian can also answer that a profile was updated. OnTask deliberately does nothing with that, because it holds no copy of any profile to refresh.
Neither job is switched off when a subscription lapses. A privacy obligation holds regardless of billing.
Deletion
| Who | How | What happens |
|---|---|---|
| You | Settings & privacy → Delete my OnTask data | Everything above that is yours — clock, history, drafts, preferences — is erased. No admin needed; it is your own data |
| A site administrator | Settings & privacy → Delete everyone's | Every OnTask record on the site is erased. The button is shown only to admins and the check is repeated on the server, so it cannot be reached by hiding the button |
| A closed account | Automatic | Reported weekly, erased daily, as above. A bounded check of each stored account also runs as a backstop |
| Retention | Automatic, daily | The periods in the table above |
Neither delete button is disabled when a subscription has lapsed. Nor does either touch the worklogs and comments already in Jira — those are the customer's own Jira data, authored by their own users, and are not the app's to remove.
Uninstall
When a site uninstalls OnTask, Atlassian deletes the app's hosted storage under its own Forge policy: a soft delete, then disposal, with a retention window during which a reinstall can be relinked to the previous data. OnTask deliberately does not race that with a wipe of its own — Atlassian's mechanism is the reliable one, and an eager wipe would destroy the relink option customers are entitled to. Anyone who wants their data gone before uninstalling has the delete buttons above.
Sub-processors and residency
OnTask has no sub-processors of its own. Everything it stores sits in Forge hosted storage operated by Atlassian as part of your site — the same position as the rest of your Jira data. Sub-processors are listed in the Security Statement.
It stores nothing outside Forge hosted storage, so it inherits whatever residency your Atlassian site has. There is no second location to pin.