This policy describes how Script Studio for Jira processes data when it is installed on a Jira Cloud site.

Who is responsible

BranchCreation S.L.U. provides the app. Your organization (the Jira site administrator who installs the app) is the customer.

Atlassian hosts the app on the Forge platform (compute, Forge SQL, and Forge key-value storage). The app does not send data to BranchCreation servers and does not have a vendor-side database.

This app is not a “Runs on Atlassian” app: an administrator may optionally push script source to a git host they choose (see Source Control below). That is the only path on which data leaves Atlassian’s products.

What the app accesses

With the site administrator’s consent at install time, the app uses these Jira scopes:

• read:jira-work and write:jira-work: read and change work items, comments, and related work data when an administrator runs or publishes a script. A manual Run in the editor uses the signed-in administrator’s identity (asUser()). Scheduled, event, field, workflow, and REST runs use the app identity (asApp()) because nobody is signed into those invocations.
• read:jira-user: receive user-related events, resolve the signed-in administrator (for example the git commit author), and show who ran a script.
• manage:jira-configuration and manage:jira-project: configure workflows, fields, UI modifications, and project settings that the workbench and published scripts need.
• write:app-data:jira: write values into this app’s own custom fields so a scripted field stays visible to JQL and boards.
• storage:app: store the encrypted git remote token and small operational marks. Script source and run history live in Forge SQL, not in this key-value store.
• report:personal-data: report which Atlassian account IDs this installation still holds, and erase those Atlassian marks as closed.

The app does not ask for Atlassian passwords or personal access tokens.

Personal data stored on Forge

Per installation, the app may store:

• Script source (TypeScript or JavaScript an administrator wrote). Comments in that source may mention people, issue keys, or other content the author typed.
• Atlassian account IDs as audit stamps: workspace owner, leftover membership rows, updated_by on files and published triggers, and actor_account_id on runs. Display names are read live from Jira when an administrator opens the UI; they are not kept as a separate profile directory.
• Run history: script path, trigger, timestamps, success or failure, clipped console output (up to 80 lines of 500 characters), and a clipped result. A script that logs issue text or account IDs will put that text in this history until it is pruned.
• REST endpoint secrets: only a SHA-256 hash of the bearer token the app issued, plus a four-character hint so an administrator can recognise which token is installed. The token itself is shown once at creation.
• Git remote token (optional): a GitHub, GitLab, or Bitbucket access token the administrator pasted, stored as an encrypted Forge secret. The editor is only told whether a token exists, not its value.
• Git author name and email: taken from the administrator’s Jira profile at commit time, written into the commit if they use Source Control.
• Encrypted installation variables an administrator saved for scripts.

The app does not store Jira passwords. Work item bodies stay in Jira unless a script copies them into source, variables, SQL tables the script created, or run logs.

Optional Source Control (data that can leave Atlassian)

If an administrator configures Source Control, the Forge backend speaks git over HTTPS to one of these hosts, and only these:

• http://github.com
• http://gitlab.com
• http://bitbucket.org

What may be sent to that customer-owned repository:

• the workspace’s script source
• commit messages
• the commit author’s display name and email from Jira

The git token is used in memory on Forge for that request. It is not stored on the git host by the app. A self-hosted or Enterprise git server is refused unless BranchCreation adds that host, redeploys, and the site upgrades the app.

If Source Control is never configured, nothing is sent to those hosts.

REST endpoints the administrator publishes

An administrator may expose a script as:

• a Forge web trigger (Forge does not authenticate the URL; the app checks a bearer token it issued), or
• the app’s authenticated REST API, called with an Atlassian 3LO token that has the app’s custom scopes (run:script:custom, read:runs:custom).

Those doors run a script the administrator already published. They do not open the editor filesystem to anonymous callers.

How data is used

• Let Jira administrators write, store, and run scripts against their own Jira site.
• Record enough run history to diagnose failures.
• Sync an optional git remote the customer chose.
• Authenticate published REST endpoints.
• Honour Atlassian’s personal-data report: forget account IDs of closed accounts (audit fields are blanked or set to the sentinel erased; membership rows are deleted).

Data is not sold, used for advertising, or sent to BranchCreation. It is not shared with third parties except Atlassian (Forge and Jira) and, if the customer enables Source Control, the git host they configured.

Retention and deletion

• Script source, published triggers, variables, and tokens remain until an administrator deletes them or the app is uninstalled. Uninstall removes Forge SQL and Forge key-value storage for that installation.
• Run history is pruned after 30 days, or when a script exceeds 200 stored runs, or a workspace exceeds 5 000 runs. An administrator can purge history from the app.
• Closed Atlassian accounts are reported and erased from the columns above. Git commits already pushed to the customer’s remote are outside this database; the app cannot rewrite that history. console lines that mention a person drop when the run is pruned.
• Native Jira issues, comments, and worklogs stay in Jira; they are the customer’s data.
• Copies already pushed to GitHub, GitLab, or Bitbucket stay in that repository until the customer deletes them.

To correct or delete personal data the app still holds, a site administrator can edit or delete files and triggers, purge run history, clear the git token, or uninstall the app. For a closed account, Atlassian’s personal-data cycle drives erasure of stored account IDs.

Roles under data-protection law

The customer decides what scripts store, who may administer the site, and whether to push to a git remote. BranchCreation processes Forge-hosted data (script source, account ID stamps, run logs, tokens) on Atlassian’s infrastructure in order to provide the app.

Contact

BranchCreation S.L.U.
https://branchcreation.com
Email: support@branchcreation.com

International transfers

Processing on Forge follows the regions Atlassian uses for the customer’s site and Forge data residency.

The app does not add BranchCreation-operated transfers. If an administrator enables Source Control, script source and commit metadata go to the git host they chose; that copy follows that host’s locations, not Forge residency.

Changes

We may update this policy when the app or the law changes. The date at the top will change. Material changes should also be reflected on the Marketplace listing.