Custom Fields Toolkit for Jira — Privacy policy

Last updated: 28 August 2026 · App: Custom Fields Toolkit for Jira · Vendor: SynapseOasis

This policy explains what data Custom Fields Toolkit for Jira collects, how it is processed and stored, and the choices available to you. Custom Fields Toolkit for Jira adds custom field types Jira does not offer natively — an Issue Picker driven by JQL, a Checklist with statuses and a transition validator, and a Masked Input with format validation — plus select list options that project administrators can manage themselves.

Custom Fields Toolkit for Jira is built on Atlassian Forge. It runs inside Atlassian's infrastructure and stores its data in your own Atlassian tenant. It makes no outbound network calls to any external service.

1. Data we collect

The data falls into two categories: configuration and results held in app storage, and Atlassian data that is read and processed in memory but not retained.

App storage (persisted inside your Atlassian tenant)

• Field configuration — the settings of each field context: the Issue Picker's JQL, display columns, quick filters and link behaviour; the Checklist's capabilities, custom statuses, validation mode and default items; the Masked Input's mask, character set, regex, algorithm and messages.
• Select list delegation configuration — which select fields, in which projects, project administrators are allowed to manage.

Transient data (read and processed in memory, not retained)

• issues and field values read to render a field or resolve an Issue Picker search
• project, field and context metadata from Jira
• user lookups from Jira, for checklist assignees and picker columns

Transient data is read through the standard Atlassian REST APIs, used to produce the result you asked for, and then discarded.

2. Personal data

• The values entered into the app's custom fields — selected issues, checklist items, masked text — are stored by Jira as ordinary custom field values on the issue, under Atlassian's own data handling, and follow the issue's permissions and lifecycle. The app also writes checklist metrics as a Jira issue property so they can be searched in JQL.
• The app's own storage holds configuration only. It does not store issue content, account identifiers, email addresses, passwords, authentication tokens, API keys or payment data.
• The Masked Input field hides its value in the user interface. Masking is a display and input-validation feature, not encryption of the underlying Jira field value.

3. Storage and retention

All persisted data is stored in Forge app storage (key-value store), provisioned for your installation and located in the Atlassian cloud region of your site. SynapseOasis operates no servers, no databases and no logs outside Atlassian, and has no standing access to your data.

Configuration is retained for the life of the installation. Job data and results are retained until you delete or reset them, until they are replaced by a newer run, or until the app is uninstalled.

4. Data sharing

• SynapseOasis does not share your data with third parties.
• There is no sale or transfer of data to third parties.
• There are no analytics, tracking or telemetry calls to external services.
• The app makes no outbound network calls at all.
• All data stays within Atlassian.

5. Security

The app runs inside the Atlassian Forge sandbox and is subject to Atlassian's platform security controls. It requests only the scopes it needs:

• read:jira-work
• write:jira-work
• read:jira-user
• manage:jira-configuration
• storage:app

Where the app acts on behalf of a user, Atlassian's permission model applies, so it cannot show a user data they could not already see. Administrative functions are restricted to users holding the corresponding Atlassian administration permission. All stored input is validated and size-capped before it is written.

6. Data deletion and retention

Deletion is controlled by the Atlassian platform, not by SynapseOasis. This section describes what actually happens, because the difference matters for a data protection assessment.

• While the app is installed, you can delete data through the app's own screens, and that deletion is immediate.
• When you uninstall the app, it runs an uninstall handler that clears its storage. Independently of that, Atlassian detaches the installation's data: it becomes inaccessible to the app, to your users and to us, right away.
• After uninstalling, Atlassian keeps the detached data for a limited period before destroying it, under Atlassian's own data retention policy. Atlassian's Forge documentation describes the storage as soft deleted on uninstall and retained for 28 days, and separately notes that a re-link request must reach Atlassian within 21 days for previous data to be restored to a new installation. That restore only happens if you ask us to raise the request, with your consent. We never initiate it.
• Atlassian's backups follow Atlassian's own schedule and are outside any app's control.

The practical consequences: we cannot delete this data faster than Atlassian's process allows, and we cannot read it after an uninstall. If you need specific data gone on a specific date, delete it inside the app before you uninstall.

Atlassian documents this in Data lifecycle for Forge-hosted storage. The retention periods are Atlassian's to change, so treat Atlassian's documentation as the current source rather than this page.

7. GDPR

• Data minimisation — only the configuration and results needed for the app's function are stored; everything else is processed in memory and discarded.
• Purpose limitation — data is used solely to provide the app's functionality inside your tenant, and is never sold or transferred to third parties.
• Data residency — all persisted data remains in your Atlassian tenant on Forge infrastructure, in the Atlassian cloud region of your site.
• Right to erasure — data can be deleted through the app while it is installed. On uninstall it is detached immediately and then destroyed by Atlassian under Atlassian’s retention policy, as described in the section above.
• Sub-processors — SynapseOasis uses no sub-processors for app data. Atlassian is the infrastructure provider and processes the data under your existing agreement with Atlassian.

8. Contact

• Email: contact@synapseoasis.com
• Support portal: Customer support portal

9. Changes to this policy

We may update this policy from time to time. When we do, we revise the last-updated date at the top of this page. We encourage you to review it periodically to stay informed about how Custom Fields Toolkit for Jira handles your data.