App privacy notice

Who this notice covers

This notice explains how Screen Self-Service for Jira handles data when an organisation uses the app in Jira Cloud, and how Timo Fitzner handles communications about the app. Your organisation controls which projects are enabled, who administers them and what information its users enter. It remains responsible for its Jira content and its lawful instructions. The provider processes app workspace data to deliver the configured service. The provider is responsible for handling its own support and business communications. The proposed Data Processing Addendum documents these responsibilities for review and adoption before customer use.

Atlassian provides Jira Cloud, Forge hosting and the Jira Service Management support platform. Its processing is also governed by the relevant Atlassian agreements and privacy information. An Atlassian certification or platform commitment is not a certification or independent audit of this app.

Purposes and legal grounds

Your organisation determines the lawful basis for its Jira administration and the instructions it gives for app workspace processing. Timo Fitzner handles support and business enquiries to respond to requests and provide the requested service, relying on contract-related steps where applicable, legitimate interests in supporting and securing the service, and compliance with legal duties where required. For processing based on legitimate interests, you may object subject to the applicable conditions. The app does not use this information for advertising or AI-model training.

Data read to provide the service

The app reads Jira permissions, project and issue-type metadata, screens and schemes, field definitions and contexts, required-field and operation metadata, and workflow references needed to check whether a change can be isolated. Some configuration and dependency reads include site-wide references, including references from projects that are not enabled in the app. Enabling one project does not make the underlying Forge permissions project-scoped.

For field checks and approval notifications, the app automatically finds an existing issue in the selected project and issue type where needed, then independently verifies its current ID, key, project and type. Legacy setups can still hold previously selected example identifiers. Jira's issue picker can return issue-summary text transiently; the app does not retain those summaries or return them to its interface. It does not need users to place issue descriptions, comments, attachments or other sensitive material into app notes. No full-issue archive is part of the app's workspace backup.

The app uses Atlassian account IDs to check authority and identify requesters, reviewers and notification recipients. Current user-profile information is requested from Jira to display names. Jira may return a name, avatar-related information or an email address depending on its permissions and visibility rules. The app's workspace records do not persist a user-profile directory; names are resolved for display when needed.

Data saved by the app

The Forge workspace stores installation and project identifiers, any retained legacy example-issue identifiers, project access settings, selected group identifiers, approval policy, before/after field layouts, change plans, request and review status, account references, timestamps, decision and operating notes, created-configuration identifiers, execution checkpoints, recovery decisions and notification states. Notification records may include recipient account IDs and previous attempts.

Audit notes are free text. Do not enter passwords, API tokens, backup passphrases, personal case details or unnecessary personal information. Operational logs emitted by the app contain a release, action and sanitised failure code rather than raw Jira responses, user identifiers or note contents. Atlassian may separately collect platform logs and usage metadata under its own service terms.

The purpose of saved change records is to authorise changes, explain what happened, detect conflicting configuration, prevent unsafe repeated actions and support controlled recovery. They are operational records and must not be treated as an anonymous dataset.

Hosting, transfers and recipients

The reviewed app runtime uses Atlassian Forge storage and Jira APIs. It has no configured external app backend, external analytics endpoint, advertising integration or AI-processing endpoint. App operation does not send Jira content to GitHub, an AI provider or the provider's own server. The separate documentation website is described below; it does not receive the app's Jira configuration or workspace records.

Jira administrators can inspect the installation's requests and audit; project administrators can inspect the requests the app authorises them to see. The app checks current server-side permissions. A configured group restriction requires current group membership in addition to project administrator rights; group membership does not grant Jira rights. Names of configured groups are resolved from Jira for display. The app stores group IDs, not group names or membership lists; membership is read for the current authorised check. Properly authorised users can download backups, and support information may be shared with the provider when you submit it to the support portal. These user-directed transfers are distinct from the app's normal runtime data flow.

Approval messages are sent through Jira's notification service to currently verified Jira administrators, subject to Jira issue access and delivery settings. Messages contain the project key, request reference, time, operation, proposed configuration-copy categories and a link to the admin inbox. Jira and the recipients' mail systems process that message. This is not a claim that every copy of app-related information remains inside Forge storage.

Forge-hosted storage follows Atlassian's residency and lifecycle controls. No independently verified EU-only placement, app PINNED status, specific cross-border transfer arrangement or complete subprocessor schedule is asserted. Platform locations and applicable processing terms depend on the actual Atlassian services and agreements.

Retention, archiving and uninstalling

The app supports administrator-controlled retention of 30, 90, 180 or 365 days. Automatic age-based deletion is off by default until a Jira administrator saves a choice. Cleanup processes eligible completed changes and administration entries in a stopped, email-paused maintenance window. Active changes, unsettled execution and unresolved notification outcomes are protected. Archiving retains records; it does not delete them.

An authorised Jira administrator can inspect stored account references, review an account deletion request, add relevant identifiers to search in notes, and approve permanent removal of eligible data. Associated completed change records are removed as whole records; surviving history pages are rebuilt with verified references. Obsolete archive-source and inactive import copies are removed as part of cleanup. This is not universal recognition of personal information: the organisation must review free text and separate copies. The current processing ceiling is 400 storage rows and 16 MiB; larger or unrecognised stores stop for operator review rather than claiming complete deletion.

The app reports retained account references and their oldest recorded provenance to Atlassian's Personal Data Reporting API, with reporting intervals and deletion/update notices tracked durably. It does not persist a display-name directory. Unconfirmed reports remain unresolved, and account notices require a deletion review; production changes remain blocked until reporting is current and notices are resolved. Paused approval emails do not pause privacy reporting. This reporting is distinct from optional approval emails and does not create a user-profile directory.

After uninstall, Forge-hosted data is handled by Atlassian's storage lifecycle. Uninstalling must not be represented as immediate permanent erasure. Reinstalling is not a guarantee that old data, settings or authority will return. The provider cannot promise a fixed purge date or retrieve an uninstalled workspace through the app. Refer to Atlassian's current storage lifecycle.

Jira screens or schemes already created by the app remain Jira configuration after an app uninstall. Disabling or uninstalling the app does not reverse them. Their identifiers and references need a separate Jira-administrator decision.

Support cases, emails and attachments are separate copies. They are retained only for the support, privacy or security matter and any necessary follow-up or applicable legal duty. Closed matters are reviewed no later than 90 days after closure before further retention; material no longer needed is deleted or reduced to the necessary record. Any justified further retention records its purpose, restricted access and next review date. A justified legal or security hold restricts use and is reviewed when that reason ends. This is manual handling, not the app's automatic cleanup. Customer-owned exports remain under the customer's control; the provider cannot delete those copies. No fixed Forge purge period is promised.

Backups and support copies

A Jira administrator can export app history as a file encrypted in their browser with their own passphrase. The passphrase is not sent to the app backend. File ownership, storage and subsequent sharing are the customer's responsibility. The provider cannot recover a forgotten passphrase. A deletion-generation marker and backend authenticity seal block imports of older or forged backups into that installation, including after loss of its workspace root while that marker remains. It does not delete customer-owned files or survive loss of every platform copy; the controller must identify and remove or quarantine obsolete external backups. Importing a compatible backup restores readable history and requires fresh setup; it does not automatically restore Jira configuration or revive approvals.

The JSM support portal receives the contact details, messages and attachments that you choose to provide. Use the appropriate request category for general, privacy or security matters. Attach redacted information first. Do not upload credentials, a backup passphrase or a full app backup in an ordinary support case. A necessary confidential transfer needs a separately agreed method and scope.

Messages sent to tfitzner90@gmail.com are handled through Google's Gmail service. Google and the sender's mail provider process email content, addresses and delivery metadata. See Google's Privacy Policy. Email is for the initial enquiry; keep unrelated Jira content and sensitive attachments out of it. A confidential support transfer needs a separately agreed method and scope. No EU-only email processing or customer-workspace processing agreement with Google is asserted here.

Documentation website

The documentation website uses Cloudflare Workers Static Assets to serve these pages, their stylesheet and logo. Timo Fitzner is responsible for this website processing. Cloudflare receives network/request information such as the visitor's IP address, requested address, time and browser/connection metadata to deliver and protect the website. This processing serves the legitimate interests of making the documentation available and maintaining its security.

The pages have no analytics scripts, tracking pixels, forms, advertising, browser storage or app backend. We do not configure a visitor analytics service or a separate access-log export. Cloudflare may process service and security telemetry under its own service arrangements. We do not promise that no network data is collected or that Cloudflare deletes it within a particular number of hours.

Cloudflare operates a global network; EU-only processing is not promised. See Cloudflare's Privacy Policy and Customer Data Processing Addendum for its roles and safeguards. These links do not establish a separate transfer arrangement with an app customer. Normal website delivery does not send your Jira workspace to Cloudflare. Opening an external link takes you to that service under its own privacy information.

Your requests and contact

For app workspace data, contact your organisation's Jira administrator or data-protection contact first, or contact tfitzner90@gmail.com or the support portal. The provider will identify the relevant controller and arrange proportionate identity verification and a secure response. For the provider's own support communications, contact the provider directly by email or through the portal if you have access.

Depending on the applicable law, you may request information, access, correction, erasure, restriction, portability or object to processing, and complain to a competent supervisory authority. These rights are subject to their legal conditions and any justified retention obligations. For Greece, see the Hellenic Data Protection Authority. Requests are handled according to applicable statutory deadlines; support response targets do not replace those deadlines. Account notices remain open until protected work is resolved and an authorised deletion review is completed; no claim of automatic deletion from every external copy is made.

Material changes to this notice will be identified with an effective date. A future billing integration, new storage destination or new support processor requires an updated assessment and notice before use.