This page describes what the software does. It is not legal advice, and it is not a statement that your use of TimeSheets complies with any particular regulation. Your organisation is the data controller for everything in this app: the lawful basis, the retention periods and the decision to collect any category of data at all are yours to make. This page exists so you can make those decisions knowing exactly what the software stores and where it goes.
1. Where your data lives
TimeSheets is an Atlassian Forge app. All of its application data is held in Forge SQL and Forge storage, which run inside Atlassian's own infrastructure. There is no TimeSheets server, no TimeSheets database, and no copy of your data on infrastructure we operate.
That means data residency, encryption at rest, tenancy isolation and backup are provided by the Forge platform and follow whatever Atlassian guarantees for your site. We inherit those properties rather than implementing our own — which also means we cannot weaken them.
One thing does leave Atlassian: outbound email. See section 3.
2. What TimeSheets stores
Personal data is identified by Atlassian account ID, not by name or email. Display names and email addresses are read from Jira when needed and are not copied into the app's own tables, with one exception noted below.
| Category | What is in it |
|---|---|
| Time entries | Account ID, project, cost centre, date, minutes, an optional free-text description, and the linked Jira issue if there is one |
| Leave | Account ID, leave type, dates, and an optional free-text reason — see section 5 |
| Approvals | Who decided what and when, any comment they left, and who they acted on behalf of if they were covering for someone |
| Personal settings | Timezone, working days, logging defaults, notification preferences, dashboard layout, pinned teammates, status message |
| Billing | Client records, hourly rates (which may be per person), the priced snapshot of each approved entry, and invoice lines naming the person whose work is billed |
| Email suppressions | Email addresses that bounced or reported the message as spam, so the app stops sending to them. This is the one place an address is stored rather than looked up |
| Erasure log | A one-way hash of each erased account, never the account ID itself — see section 7 |
There is no analytics SDK, no tracking pixel, no session recording and no third-party script in the app interface. Nothing about how your people use TimeSheets is sent anywhere.
3. What leaves Atlassian
Exactly one thing: email. TimeSheets sends notifications through Amazon SES, which is declared in the app manifest as the only permitted outbound destination (*.amazonaws.com). Every other operation stays inside Atlassian.
Two configurations are possible, and they differ in who the data reaches:
- Your own SES account. You supply credentials in Admin Settings, and mail is sent through your AWS account. No third party is involved. Credentials are stored write-only — no part of the app can read them back.
- The built-in sender. If you provide no credentials, mail goes through our SES account, which makes us a processor and AWS a sub-processor for message content in transit.
Email content includes the recipient's address and display name, and the detail relevant to the notification. For leave notifications this includes the leave type name — so if you have Sick Leave enabled, the words "Sick Leave" alongside a person's name will transit your email path. If that matters to you, use your own SES account, disable the specific leave types, or switch leave notifications off.
Excel and PDF exports are generated in your browser. The file is never uploaded anywhere; it is built locally from data the server already sent you.
4. Jira permissions the app asks for
| Scope | Why |
|---|---|
| read:jira-work | Read issues so time can be logged against them |
| write:jira-work | Mirror approved entries into native Jira worklogs, if you enable worklog sync |
| read:jira-user | Resolve account IDs to display names so screens show people rather than identifiers |
| read:email-address:jira | Find the address to send a notification to. Addresses are not stored except on the suppression list |
| read:project:jira | List projects and determine what each person can browse |
| read:board-scope:jira-software read:sprint:jira-software | Sprint context on reporting screens |
| manage:jira-configuration | Determine who is a site or project administrator, which is what the app's own permission checks are built on |
| storage:app | The app's own database |
The app never reads issue content beyond what is needed to display and link an issue, and it does not read Jira data for projects the requesting person cannot already browse.
5. Special-category data, and how the app avoids it
Leave is where sensitive data most easily enters a timesheet app, and it does so in two ways that are easy to miss.
The leave type itself is an inference. "This person took Sick Leave on twelve days" is health information whether or not anyone typed a reason. Maternity and Paternity reveal family status; Bereavement reveals a death in the family. Because of that, TimeSheets seeds those leave types switched off. A new installation collects no special-category data at all until an administrator turns a type on, having decided they have a basis for it. The types are present and correctly configured, so enabling one is a single toggle — but it is a deliberate act, not a default.
A generic Leave type that implies nothing is enabled by default. If your HR system already holds the reason, routing everything through this type keeps the category out of Jira entirely.
The reason box is optional, and treated as sensitive. It is labelled optional, the hint text tells people they do not need to give a medical or personal reason, and the field is length-limited. Beyond that:
- The approval queue does not contain the text. That list loads for every approver on every project a request touches; only a marker saying whether a reason exists is sent.
- The words are fetched one request at a time, by the approver who is actually deciding it.
- Once the request has been decided, the reason is no longer retrievable by approvers at all. Only the person who wrote it can still read it.
- It is not searchable. You cannot type a medical term into a filter box and get back a list of people.
6. Retention
TimeSheets can delete data on a schedule, per category. Every window ships set to "keep forever" and deletes nothing until an administrator changes it. That default is deliberate: deletion cannot be undone, and an app upgrade that quietly started removing people's leave and timesheet history would be worse than continuing to hold it while you decide.
| Category | Default | Notes |
|---|---|---|
| Approval history | 365 days | The only window with a non-zero default; this table grows with every decision and sweep |
| Leave history | Keep forever | The category with the strongest argument for a short window |
| Timesheet history | Keep forever | Entries on an issued invoice are never deleted — see section 8 |
| Email suppressions | Keep forever | Deleting these means the app may start emailing an address that previously bounced or complained |
The sweep reports what it deleted and what it declined to delete. A retention job that silently skipped protected rows would look identical to one with nothing to do, and you would never learn your policy was not being applied.
7. Erasing one person
A site administrator can erase everything held about a single Atlassian account. Because an erasure request and a business record can genuinely conflict, the app resolves it per row rather than per person:
| Kind of record | What happens | Why |
|---|---|---|
| Their own data | Deleted | Timesheets, leave, preferences, dashboard, status, pins. These exist only because the person does |
| Things they did to someone else's record | Identity replaced, record kept | An approval reading "approved by [removed]" destroys the audit trail of the person whose timesheet it was — and that person did not ask for anything |
| Work on an issued invoice | Identity replaced, amounts untouched | An invoice is a financial record you are likely required to keep. Every figure stays exactly as billed |
| Free text anywhere | Cleared | Leave reasons, entry descriptions, status messages and decision comments are removed even from records that are otherwise kept. An invoice needs the hours and the amount; it has never needed the words |
Where an identity is replaced, it becomes a stable label such as Former member #a1b2c3d4 — the same label everywhere, so one person still reads as one person across an invoice, an approval and an audit trail.
A preview counts exactly what would be removed and changes nothing, so you can confirm the request names the right person before anything irreversible happens.
The erasure log records that an erasure happened, when, and by whom — storing a one-way hash of the account rather than the account itself. A record of "we erased this person" that named the person would defeat the purpose. The hash is salted per installation, so the same individual does not produce the same value in two different sites.
8. Why some data survives erasure
If a time entry has been billed on an issued invoice, deleting it would leave your organisation unable to substantiate an amount a customer was charged. TimeSheets keeps those rows, replaces the identity on them, clears any free text, and marks them so they no longer appear in timesheets or reports.
The invoice itself is designed for this: the line carries a name label separate from the account reference, so removing the identity does not change a single figure. An invoice's total still equals the sum of its lines, exactly, after an erasure.
Uninvoiced work is genuinely deleted. This protection applies only where a financial record actually exists.
9. Giving someone a copy of their data
A site administrator can export everything held about one account as a JSON document. It is assembled from the same list of tables that erasure uses, so the two cannot disagree — an export cannot tell someone their data is not held while erasure knows that it is.
Each section of the export says what erasure would do to those rows, so the person can see in advance what would go and what would be kept. If the export hits its size limit it says so rather than presenting a partial answer as a complete one. Exports are recorded in the audit trail.
10. Who can see what
Access follows Jira. Nobody sees a project they cannot already browse, and reporting is limited to projects where the viewer is an approver or an administrator. A few specifics are worth stating plainly:
| Data | Who can read it |
|---|---|
| Someone else's time entries | Approvers and administrators of the project the time was logged to |
| A leave reason | The author, and the approver deciding that specific request while it is still pending |
| Rates and money | Billing administrators only, reads included. A rate is close to a person's pay rate, so an amount is never shown to an approver merely because they can see the hours. Your own rate is not visible to you in your own timesheet |
| Cost centre budgets | Hours allowances are visible to people who can see the cost centre; money budgets are billing-administrator only |
| Erasure and export | Site administrators only, and both are audited |
| Site configuration | Readable by any licensed user of the app. This covers policy settings such as working hours, the lock window and approval mode, plus the account ID of whichever administrator last changed each one. It contains no rates and no credentials — email credentials are write-only and cannot be read back by any part of the app |
For the full role model, see Permissions & Security.
11. What you still need to decide
The app gives you the controls. These decisions are not ours to make and the software cannot make them for you:
- Whether to enable special-category leave types at all, and on what lawful basis if you do.
- How long to keep each category of data. The defaults keep everything; that is a starting point, not a recommendation.
- Whether to use your own SES account, which removes a third party from your email path.
- Whether to tell your people that leave and timesheet data is held in Jira, and what your notice says about it.
- Whether you need a data processing agreement covering the built-in email sender.
If something on this page is unclear or you need detail it does not cover, get in touch — a question about data handling is one we would rather answer twice than not at all.