PRO - Privacy Policy

Last updated: Oct 2, 2026

Timesheet Management PRO ("the app") is a paid Jira app for logging time and running a weekly submit → approve → (optionally forward) → lock timesheet workflow, with team-based approval routing and reporting. Most of what it shows is read live from your Jira site using your own Jira permissions. Because it runs an approval workflow, it also keeps some durable records of its own - more than the free tier, Timesheet Management LITE, does. When Atlassian tells the app that a user's Atlassian account has been closed, the app removes or anonymizes that person's personal data from its own storage. See "Data retention" and "Account closure and erasure" below.

When you use the app, it calls Jira’s own REST API on your behalf (using your existing Jira session and permissions) to:

• Read and write worklogs (time entries) on work items

• Read work item details - summary, status, resolution date, time-tracking fields, and change history (the Time in Status and Capitalization reports are built from status and assignment history)

• Read your own user profile (account ID, display name, avatar, time zone, locale), read other users’ names and avatars for display, and search for users (for example, to pick an approver or add a team member)

• Read the membership of a Jira group - when a group is set as an approver or as the Timesheet Management admin group, or to send a summary email to its members

• Read space (project) information, including the space lead

• Read the site’s active Time Tracking Provider configuration and its working-hours / working-days settings, and check whether you are a Jira site administrator

Most of these calls run with your own Jira session and permissions. A few run under the app's own access instead: the daily scheduled jobs (summary emails, the deleted-worklog check, personal data reporting and the Capitalization cache build) and group membership lookups, because those have no signed-in user to act as. The Capitalization report is built from a cache that the app creates under its own access. As a result, anyone who can open the Capitalization report can see work item summaries and assignees from spaces they cannot open in Jira. The space filter lists in the app show the names and keys of all spaces on the site, including spaces a user cannot open in Jira.

The app’s own storage (hosted on Atlassian’s Forge platform, in the same infrastructure and data residency as your Jira site) holds:

1. Site and team settings - admin-configured options: the approver mode and the account IDs or group IDs of configured approvers and Timesheet Management admins; the app’s teams and their members, leads, and linked spaces; the billing-rate and capitalization policy; period-locking rules; the week-start day and weekend days; and the daily-digest settings. Mostly non-personal, but it does include the names and account IDs of the people named as approvers, admins, or team members.

2. Timesheet workflow records - for each submitted week and space: the submission (who submitted, which week and space, and your optional note to the approver); the approval (who approved and when, plus a frozen snapshot of that week’s worklogs - dates, durations, and comments - kept so the approval record stays meaningful if the worklogs are later edited or deleted directly in Jira); forwarding records (who forwarded to whom, and any note); and alerts (a week was rejected and the reason, an approval was forwarded to you, or an approved worklog was deleted in Jira). These records name the people involved and can contain free text that users write. The app also keeps a history log of each workflow action (submit, recall, approve, unapprove, reject, forward, reopen, lock and unlock). Each entry records the account IDs of the timesheet owner and of the person who acted, the week and space, and any comment, reason or message written at the time. It stores no display names.

3. Billing rates (Timesheet Management admins only) - used by the Billables report. For each person, the app stores the rate amount, currency, vendor name and effective dates against their account ID. Names and avatars are not stored with the rate. The app looks them up from Jira each time the rates are shown. An administrator enters these rates, and the app does not collect them automatically.

4. Report caches - a precomputed cache for the Capitalization report (one record per work item per month, built from Jira's own change history, including past assignees and their names) and a precomputed cache of the Approvals "View all" queue. Both are rebuilt automatically on a schedule and hold nothing that isn't already in Jira or in the workflow records above. When a user runs a large Capitalization report, the app also keeps its results briefly so the report can load in the background. It deletes them as soon as the report has loaded.

5. Saved report views (personal data, user-chosen) - each user can save named filter combinations for the Timesheet, Billables, Time in Status, Capitalization and Teams reports. A view saved as "shared" is visible to other users. If a saved view's filter includes other people, their account IDs and display names are stored as part of it. This only happens if the user chooses to save such a filter.

6. Error log - up to the last 100 errors encountered by any user, each with a timestamp, the error message and technical detail, and which part of the app it happened in. It records only an account ID for who hit the error, not a display name. Visible only to Jira admins, who can clear it at any time from the app’s settings.

7. Cached site configuration - the site’s active Time Tracking Provider status, whether a sibling app is installed, and working-hours / working-days settings. Entirely non-personal and site-wide. Cached for up to 10 minutes to reduce redundant requests to Jira, then refreshed automatically.

8. Capitalization Past reports - At the end of each month, the app saves a copy of that month's Capitalization report inside your Jira site. The copy includes Atlassian account IDs and display names of the people whose time it counts. Copies are kept for 12 months and then deleted automatically. If Atlassian reports an account as closed, the app removes that person's account ID and name from every saved copy within 7 days.

9. Capitalization REST API - Timesheet Management admins can read these saved reports through a read-only REST API. Access needs an OAuth token with the read:capitalization-report:custom scope, and the caller must be a Timesheet Management admin. The API returns the same account IDs and display names as the report. Data retrieved through the API is then held by the caller's own systems and is covered by the caller's own privacy obligations.

10. Repeating worklogs - when a user repeats a worklog across several days, the app keeps a record that links those worklogs together, so they can later be edited or removed as a group. The record stores the account ID of the person who created the series. It does not store a name.

The app does not maintain a separate, running database of your worklogs or activity. Every worklog you create through the app is an ordinary, native Jira worklog - the same record Jira would create through its own UI. The one place worklog content is copied into the app’s own storage is the approval snapshot described above: a frozen record of a week’s worklogs at the moment it was approved. If you uninstall the app, your worklogs remain in Jira untouched. The app’s own storage is removed as described under "Data retention" below.

If an administrator enables it, the app asks Jira to send a short daily summary email - to the configured approvers and the Timesheet Management admins - on working days when a timesheet is waiting for approval or a resolution-date issue needs fixing. Jira sends these emails; the app does not use an external email service. The email contains only a prompt to open the app, not timesheet detail.

The app reports the accounts it stores data for to Atlassian once every 7 days. When Atlassian reports an account as closed, the app erases or anonymizes that person's data within 7 days. When Atlassian reports that a person's profile changed, the app updates the name it keeps for them in its settings. For each closed account the app then:

• Replaces the account ID with a placeholder in submissions, approvals, forwards and billing rates, so the workflow history stays intact but is no longer linked to that person;

• Removes the account ID and name from the Capitalization cache and from every Capitalization Past report;

• Deletes that person's alerts, their cached Approvals queue entries and any Capitalization report results still being loaded for them;

• Removes the person from approver lists, admin lists and teams in the app's settings;

• Deletes the saved views the person owned, and removes the person from any other user's saved view filters;

• Removes the account ID from error log entries and from repeating worklog records, and leaves the rest of each record in place.

• Removes the account ID from the approval history log, and leaves the rest of each entry in place.

If a record cannot be updated, the app logs it and retries on the next daily run.

What remains: Some of the app's internal storage keys contain the Atlassian account ID. An Atlassian account ID is an opaque identifier. No name, email address or other detail is kept with it once the account is closed. The worklog snapshots inside approvals are kept, with comments and durations, and are no longer linked to the closed account.

The app doesn’t send data to marketing, analytics, or advertising third parties, and has no external network access beyond your own Jira site’s API. Personal data may be processed by RLC Digital personnel in Singapore, by Atlassian’s Forge platform (which hosts the app), and - subject to the restricted-access terms in our DPA - by a US-based freelance developer. See the Data Processing Addendum for full sub-processor and transfer details.

• Settings, teams, and billing rates persist until changed by an admin, the app is uninstalled, or until the person's Atlassian account is deleted.

• Submissions, approvals (including the worklog snapshot), forwards and alerts persist as the app's record of the workflow until the app is uninstalled, or until the person they name has their Atlassian account closed, at which point they are anonymized as described above. There is currently no other automatic expiry.

• The approval history log is kept until the app is uninstalled. Entries are not deleted earlier.

• Report caches are overwritten on each scheduled rebuild and removed on uninstall. Saved report views persist until the user deletes them or the app is uninstalled.

• Capitalization Past reports are kept for 12 months after the month they cover, then deleted automatically. They are also removed on uninstall.

• Repeating worklog records are removed when all but one of their worklogs have been deleted through the app. Otherwise they persist until the app is uninstalled.

• Error log entries are capped at the 100 most recent, can be cleared by an admin at any time, and are removed on uninstall.

• When the app is uninstalled, Atlassian removes the app's own stored data from the app and keeps it for up to 28 days before deleting it permanently, so it can be restored if the app is reinstalled and a restore is requested within 21 days.

• Worklogs and all other Jira data are governed by your Jira site’s own retention policies - the app has no independent retention of its own.

We’ll update this page if what the app stores or accesses changes. Check the "Last updated" date above.

support@rlc.digital