Runphase Privacy Policy
Runphase is an Atlassian Forge app for running planned changes against a Jira issue. You write the procedure, work through it step by step while the change is happening, and are left with a record of what was done.
This policy covers what the app reads, what it keeps, and where that data sits. There is not a great deal of it, because the app does very little with your data.
Nothing leaves Atlassian
Runphase has no egress. Its manifest declares no
remotes and no external permissions, which means the
app is not able to make a network request to anywhere outside Atlassian.
There is no analytics, no telemetry, no error reporting service, no advertising, and no third-party processor of any kind. Atlassian reports every deployment as eligible for Runs on Atlassian, so the app's code and its data stay inside Atlassian's own infrastructure and data residency guarantees.
Skram Systems cannot read your data. Everything Runphase keeps lives in Forge app storage, scoped to your installation. There is no database on our side, no dashboard, and no export.
What the app reads
Runphase asks for four permission scopes and no others.
| Scope | What it is used for |
|---|---|
read:jira-work |
Reading the Jira issue a run belongs to: its key, id, project key, summary and status. This identifies the change, and captures how the issue looked when the window opened. |
read:jira-user |
Resolving Atlassian account ids to display names, so that a run's history reads as names rather than ids. |
storage:app |
The app's own storage, described below. |
report:personal-data |
Telling Atlassian which account ids this app is holding, so that Atlassian can tell the app when one of those accounts has been updated or closed. Described under account closure below. |
The first three are read-only as far as Jira is concerned, and the fourth does not touch Jira at all. Runphase never writes to Jira. It does not create, edit, transition or comment on issues, and nothing you record during a run is pushed back into Jira.
Permission checks run as the signed-in user, so a person sees only the runs whose underlying Jira issue they could already open. Where Jira refuses to answer, or cannot, the app fails closed and says so on screen.
What the app stores
All of it in Forge app storage, scoped to your installation.
- Run records: the Jira issue key and id, the project key, the issue summary taken as the run's title, the run's state, its planned and actual windows, and timestamps.
- Atlassian account ids for whoever created, started and closed a run, and for the author of each note or deviation. Account ids, not names.
- The text you enter. That means plan steps and their expected results, success criteria, rollback procedures, step notes, deviations, evidence references, and the reason given for failing or rolling back a run.
- An append-only event log of what happened during the run.
- Templates saved from a run's plan, so that a procedure can be reused. A template records the Jira issue it was saved from, and is offered only to people who could open that issue.
- A per-viewer cache of display names: a map of Atlassian account id to display name, capped at 200 entries, each name held for six hours and each "no name available" for fifteen minutes. It saves asking Jira again on every page load, and it is keyed to the viewer because the lookup runs with that viewer's permissions.
Sensitive content, and what you can do about it
Runphase is an execution record, not a secrets repository.
Before storing text, the app screens it for patterns that look like credentials, and blocks the write with a warning naming the field. Engineers paste command output for good reasons, so that block can be overridden. The override is a recorded act with an author against it, rather than a silent default.
The screen is a heuristic, and it will not catch everything.
Redaction. Anything recorded can be redacted afterwards, including on a run that has already closed. A redaction overwrites the value everywhere the app holds it: the live record, the frozen copy in the run record, and the event log. What it leaves behind is a marker saying who redacted it and when, and never what it was.
Redaction is not containment, and the app says as much at the point where it offers it. A credential that was recorded may already sit in an export somebody took, in a Jira comment, in a chat message or in a screenshot, and Runphase can reach none of those. So if a live credential has been recorded, rotate it. Redaction removes it from this app. Only rotation makes it harmless.
When an Atlassian account is closed
Almost everything personal in Runphase is an account id. Names are not stored in the record at all: a run holds the account id of whoever created, started or closed it, and of the author of each note and deviation, and the name you see on screen is looked up when the page loads and held in the cache described above for at most six hours.
Because the app keeps those account ids, it reports them to Atlassian on a
recurring cycle, which is what the report:personal-data scope is
for. Atlassian answers with any account that has since been updated or closed.
An updated account means the cached name is stale, and it is dropped so the
next page load asks again. A closed account means the person's Atlassian
account no longer exists, and their cached name is erased rather than left to
expire.
The account id itself stays in the records it appears in. A run says who carried out a change and when, which is the thing the app exists to produce, and a record that quietly loses its actors is not much of an audit trail. If you need a particular record altered, redaction works on any run including a closed one, and the contact address at the top of this policy reaches a person.
Retention and deletion
Once a run reaches a terminal state its record is immutable, and notes are append-only throughout. A record that can be edited after the fact is not worth keeping, which is rather the point of the app. Redaction, above, is the one exception.
Runphase deletes nothing on a schedule and has no retention timer.
Uninstalling the app removes its storage under Atlassian's standard Forge app data deletion process. If you need data removed before that, write to the address at the top of this policy.
Cookies and tracking
Runphase sets no cookies and uses no tracking technology. Its interfaces run inside Atlassian-provided iframes, and it puts nothing in your browser beyond what Atlassian itself sets.
Changes to this policy
Material changes will appear here with a new effective date. The app's scopes and its egress posture are declared in its manifest and enforced by Atlassian, so a change in what Runphase can reach is not something that can happen quietly. It takes a new version, and for a new scope it takes your consent again at install time.