Data processing
What the app reads, sends, and keeps. This technical overview supports your review of Jev for Jira; it is not a contractual Data Processing Agreement.
About this document
This page describes the current technical data flows, storage, retention, and controls in Jev for Jira. It is not a Data Processing Agreement (DPA), does not establish contractual processing terms, and does not replace the Privacy Policy or App Terms.
If your organisation requires a DPA, contact We The Folks to arrange and complete the applicable agreement before using the app with data that requires one. Provider terms, transfer arrangements, and your organisation’s requirements need to be reviewed as part of that process.
How classification data moves
The Forge backend reads the Jira issue using an authorized administrator identity. It expands Jira variables in the configured prompt and outcome descriptions, then sends those instructions, outcome labels, referenced Jira values, and the model identifier to OpenRouter. OpenRouter routes the request to TypeSafe’s typesafe/jev-1.13 model.
New rules send the Jira values explicitly referenced in the prompt or outcome descriptions. Older source-field rules also send their selected source field until an administrator reviews and saves their conversion to explicit variables. Values referenced only by action templates are expanded locally and are not sent merely because they appear in an action.
The model returns configured choices and probabilities. The application validates the response and plans only the actions configured by the administrator. A Test previews those actions without changing the issue; an eligible automatic run can apply them in Jira.
Issue text and administrator-authored templates can contain personal or sensitive information. Converting Jira rich text to plain text reduces embedded metadata; it does not guarantee that the text is free of personal data.
Application data inventory
Application records are held in installation-scoped Forge storage. Project rules and activity are also scoped by project. The publisher’s OpenRouter credential is held separately in an encrypted Forge environment variable.
Retention and deletion boundaries
Activity and execution receipts expire no later than 14 days after their original run creation time. For a recovered event, the earlier deadline of 14 days from its original queue time also applies. Retries, progress updates, and move continuations do not renew these deadlines.
Expired activity and receipts are excluded from application access immediately. Storage expiry and cleanup remove stored records asynchronously, so physical deletion can lag the access cutoff. Deleting a rule does not retrospectively delete its earlier activity.
The account-reporting process removes explicit administrator references that Atlassian reports as closed or updated. Affected rules are disabled; affected receipts require review; consent granted by an affected account is removed. It does not find every personal detail written into arbitrary prompts, rule names, labels, or action values.
Data requests involving free text or a specific installation need an authorized, installation-specific review. Provider-side copies and Forge platform logs follow their respective service policies, not the application’s 14-day storage deadline. Uninstalling does not guarantee immediate physical deletion from every system.
Services involved
The Jira app and this public website use different services. Website hosting and font delivery are separate from the app’s classification path.
External processing and consent
A Jira site administrator must authorize external processing for the installation before a model request is allowed. Project administrators configure which Jira values the classification uses. The Inputs summary in the editor helps them review those references.
Withdrawing consent blocks new classifications and tests. It cannot recall data already transmitted, cancel an accepted Jira move, or guarantee that every edit in an already-started action batch stops. Recovery rechecks current consent, permissions, and the original enabled rule revision before resuming.
The app does not enforce provider zero data retention, a no-training setting, or a fixed external processing region. Classification leaves Atlassian; this page makes no promise that all data stays in Atlassian or in a particular country. Provider handling must be assessed under the applicable provider terms and agreements.
Health checks and operational logs
The administration page checks service availability at opening and approximately every five minutes while it remains open. A recovery scheduler also checks availability when pending work is due. Both use fixed synthetic data and application-owned instructions, require site consent, and send no Jira issue content. They do not edit tickets or create Activity log entries.
Activity and execution receipts exclude full issue bodies, expanded action values, raw model responses, and API keys. Rule names and outcome labels copied into activity can still contain personal text.
Runtime failures use sanitized public messages. Forge operational logs may contain identifiers, statuses, and safe error information; their retention is governed by Atlassian’s service policies.
Contact
For data-processing questions or to arrange applicable agreements before use, contact [email protected].
See the Privacy Policy for privacy requests and the support guide for safe information to share.