Data Handling and Permissions
OKR Tracker runs entirely on Atlassian — your OKR data never leaves your cloud. This page explains where the app keeps its data, the exact keys it uses, and what each permission scope is for, in plain language.
Where your data lives
All app data is stored in Forge KVS (the storage:app scope). Your native Jira issues remain the source of truth for identity, summary, assignee, and workflow status. The KVS holds the OKR-specific attributes and time-series that Jira itself does not model — progress values, check-in history, settings, audit entries, and cached metrics. Because everything sits in Forge storage on Atlassian's infrastructure, your data stays inside your Atlassian cloud.
Lists — such as all Objectives or all check-ins — are read with cursor pagination via kvs.query().
KVS key reference
| Key pattern |
What it holds |
cfg:settings |
App settings (project mapping, scoring rules, quarters, reminders, roles) |
obj:{issueKey} |
Objective attributes for the given Jira issue |
kr:{issueKey} |
Key Result attributes for the given Jira issue |
ci:{krKey}:{year}:{week} |
Immutable weekly check-in for a Key Result |
metrics:dashboard |
Cached dashboard metrics |
audit:{ts}:{rand} |
Audit log entry |
Scopes, in plain language
Each scope the app requests maps to a specific, narrow job:
- storage:app → stores the OKR attributes, weekly check-ins, settings, audit log, and cached metrics in Forge KVS.
- read:jira-work → reads issues, projects, and issue types to render the hub, the issue detail panels, and the reports.
- write:jira-work → sends reminder and escalation notifications and writes the rollup back to the Objective.
- read:jira-user → resolves the current user's group membership so the app can map them to an app role.
- manage:jira-configuration → used only during one-time onboarding to create the Objective and Key Result issue types, the custom fields, and the "realizes" link type.
Native issue create and view run through Jira's own dialogs and need no extra scope.