Workflow Toolkit for Jira — Privacy policy

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

This policy explains what data Workflow Toolkit for Jira collects, how it is processed and stored, and the choices available to you. Workflow Toolkit for Jira adds AI-powered workflow modules — conditions, validators and post functions. You describe the rule in plain language and the app turns it into a check or an action that runs on the transition.

Workflow 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)

• Audit events, one row each: what ran, when, the issue key, the transition name, the counts of the actions taken, and — for a validator — the AI-written reason for its verdict. No account ID and no user name is stored on the row. Retained for 90 days.
• The generated expression and its AI-written title, recorded each time you use Generate Expression.
• Token usage — the prompt, completion and total token counts of each AI call.
• Your rule configuration is not stored by the app. The rule description, rule text, generated expression, selected fields, context sources and enabled tools are stored by Jira, inside the workflow definition, exactly like the configuration of any built-in condition, and are covered by Atlassian's own data handling.

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

• the issue being transitioned: its field values, and — for a post function — its comments, change history, links, sub-tasks and available transitions, read at transition time
• workflow, transition, field and issue type metadata from Jira
• Jira is read with the app's own access rather than the acting user's

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

2. Personal data

• Issue content is read to evaluate a rule or run a post function, and no copy of the issue is retained. An audit event does keep the validator's written reason for blocking a transition, which the AI derived from the issue — that is what answers "why was this blocked?" in the audit log.
• No Atlassian account ID is stored. An audit event records what the app did on a transition, not who asked for it. One thing does name people, and it is worth stating plainly: a validator's written reason is prose the AI composed over the issue, and the context it is given names people — assignee, reporter, comment authors, attachment uploaders — by display name, so a name can appear inside that sentence. It is a name in prose with no account attached, so it cannot be looked up or reported to anyone; what removes it is the 90-day retention deleting the row.
• Attachment contents are never read; only file metadata is included, and only when that context source is enabled.
• Atlassian's Personal Data Reporting cycle runs daily and currently reports nothing, because the app holds no account ID to report. The cycle is kept, and its erasure path with it: if the app ever stores an account ID again, a closed account's records are deleted — the whole record, not just the name on it, because the reason text on an audit event can describe the same person.
• The app does not collect email addresses, passwords, authentication tokens, API keys or payment data.

3. AI processing

The AI features of this app run on Forge LLM, the AI runtime Atlassian provides inside the Atlassian platform, using Atlassian-hosted models. SynapseOasis operates no AI infrastructure of its own, holds no API keys to third-party AI providers, and never sends your data to one. Prompts are processed by Atlassian's service and are not used by SynapseOasis to train any model.

The following data is included in prompts when an AI feature runs:

• the rule you wrote in plain language when configuring the condition, validator or post function
• the name, ID and type of the custom fields you selected under Fields Involved
• for a post function, a base context that is always sent: the issue's key, summary, full description text, status, priority, issue type, assignee, reporter, resolution, labels, components, fix versions, time tracking, parent, sprint, the transition being performed, the transitions currently available on the issue, its issue links, its sub-tasks with summary/status/assignee, and your site's issue link types
• for a post function, the context sources you enable on top of that: up to the 50 most recent change history entries, the 20 most recent comments, attachment metadata (name, MIME type, size, uploader and upload date — never file contents), and the custom fields you select together with their allowed values

Model responses produce the result shown in the app and, where the app records a decision, are stored as described in section 1. AI features run only when enabled by your administrators.

4. Storage and retention

All persisted data is stored in Forge app storage (key-value store) and Forge SQL, both hosted by Atlassian, 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.

5. 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.

6. 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
• send:notification:jira
• storage:app
• report:personal-data

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.

7. 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.

8. 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.

9. Contact

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

10. 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 Workflow Toolkit for Jira handles your data.