Security & Data Residency
How Time Tracking Customfield runs from a security and data point of view: where code executes, where data lives, and how it respects your Jira permissions and data residency.
Hosting model: runs fully on Atlassian Forge
The app runs entirely on Atlassian Forge in the "Runs on Atlassian" model.
All compute for the app (backend logic, view/edit components, configuration) executes in Atlassian-managed infrastructure.
There are no vendor-hosted servers, databases, or external services in the data path for normal operation.
In practice: when the app is installed, all logic stays within the same cloud platform that already hosts your Jira Cloud site.
Where your data lives
All field values are stored as Jira custom field data on the issue, alongside other Jira fields.
For each Time Tracking field instance, Jira stores the original estimate, time spent, and remaining estimate — in both numeric (seconds) and human-readable forms.
For each Duration field instance, Jira stores a single duration value in numeric (seconds) and human-readable forms.
The app does not replicate this data into an external database.
Any transient processing (parsing, validation, calculations) happens inside Forge and the results are written back to Jira as field values or worklogs.
From an admin perspective, the data lifecycle is the same as for any other Jira custom field: created, updated, and stored inside Jira Cloud.
Data residency
Time Tracking Customfield follows your Jira Cloud data residency settings.
Custom field values and worklogs used by the app are stored in the same region as your Jira issue data.
Forge execution and storage participate in the same regional controls as other "Runs on Atlassian" apps, so the app does not introduce a new, separate data location.
If your organisation relies on a specific region for compliance, the app respects that by design.
No data egress to third-party infrastructure
The app does not send issue data, time values, or worklogs to third-party servers.
There is no external queue, analytics pipeline, or vendor-managed database receiving your Jira content.
Any diagnostics (logs) are stored inside Atlassian's logging systems for Forge apps and are accessible only through the Atlassian ecosystem.
Your time tracking data does not leave Atlassian Cloud because of this app.
Permissions and access control
All operations run in the context of the current Jira user.
The app respects Jira's existing permission model:
if a user cannot see or edit an issue, the app cannot see or edit it on their behalf,
time tracking fields behave like other fields in terms of who can view or update them.
The app uses only the minimal Jira scopes required to read and update issue fields and worklogs (for example, read/write Jira work), and does not request broader scopes like admin or user directory access.
This means the app cannot bypass your existing Jira permission schemes, project roles, or issue security levels.
Search, reporting, and exports (security view)
When you use Time Tracking or Duration fields in JQL, dashboards, or exports, Jira uses the same index and export mechanisms as for built-in fields.
The app simply defines indexed aliases (for example
OriginalEstimateSeconds,RemainingEstimateSeconds,DurationSeconds) and Jira takes care of indexing and querying.CSV exports and API responses include these fields just like any other custom field, under the control of Jira's own access checks.
No additional reporting backend is introduced; everything runs through Jira's native search and export layer.
What this means for admins
From a security and data residency perspective, Time Tracking Customfield:
runs inside Atlassian's infrastructure (Forge, Runs on Atlassian),
stores its data only in Jira Cloud as custom field values and worklogs,
honours your Jira permissions, project configurations, and data residency settings,
avoids any external infrastructure, databases, or services that could receive your issue data.
See also
TroubleshootingLicensing, Support & ContactLast updated