1. Overview
Jira Governance & Admin Helper (“the App”) is a Jira Cloud administration toolkit built on Atlassian Forge. It is developed and maintained by TechClimbs. This policy describes what data the App accesses, stores, and processes.
The App runs entirely on Atlassian’s Forge platform. No data is transmitted to external servers operated by TechClimbs or any third party. The only external network calls are to api.atlassian.com — for the Atlassian Admin API (when an Organization API key is configured), the Automation REST API (when managing automation rules with per-session credentials), and the Teams Public REST API (when managing teams with per-session credentials). Teams credentials (email + API token) are used only during the active session and are never stored in Forge storage.
The App accesses Jira data through official Atlassian REST APIs to provide administration features. All data is fetched live and cached in browser memory only during the active session.
| Access Type | Data |
|---|---|
| Read | Projects, workflows, statuses, resolutions, custom fields, screens, priorities, agile boards, attachments, components, versions, and their associated schemes |
| Read | Permission, notification, workflow, issue type, screen, and priority schemes |
| Read | User accounts: display name, email, account ID, account type, active status, timezone, group memberships, application roles |
| Read | Groups, application roles, project roles, and group memberships |
| Read | Dashboards, filters, gadget configurations, and share permissions |
| Read | Automation rules: names, states, owners, actors, scopes, labels (via Automation REST API with per-session email + API token authentication) |
| Read | Jira audit log records: configuration changes, user management events, permission updates (read-only, used by the Jira Audit Log Analyser feature) |
| Read | Organization data via Atlassian Admin API: user last-active dates, product access, directories, teams (only when API key is configured) |
| Write | Scheme assignments to projects, project role assignments, dashboard/filter ownership changes, automation rule enable/disable/transfer |
| Delete | Workflows, schemes, custom fields, screens, statuses, resolutions, priorities, issue types, projects, users, dashboards, filters, boards, attachments, automation rules, components, versions, teams (only when explicitly requested by an administrator) |
| Suspend | User access via Atlassian Organization Admin API or JSM customer API (only when explicitly requested by an administrator) |
The App stores minimal configuration data in Forge storage. No user personal data (names, emails, etc.) is permanently stored.
| Key | Content | Purpose |
|---|---|---|
user-mgmt-api-key |
Organization API key | Authenticate Admin API calls (optional, admin-configured) |
user-mgmt-api-configured-by |
Account ID of configurator | GDPR: identify who configured the key for personal data reporting |
| Key | Content | Purpose |
|---|---|---|
org-id |
Organization UUID | Identify the Atlassian organization for Admin API calls |
org-name |
Organization name | Display in Settings UI |
primary-directory-id |
Directory UUID | Target directory for group and product access operations |
primary-directory-name |
Directory display name | Display in Settings UI |
user-mgmt-experience |
“new” or “legacy” | Detect which user management API version to use |
app-access-level |
Access level setting | Controls which admin group level can use write operations |
app-access-readonly |
Boolean flag | Enable or disable read-only mode for non-primary admins |
bulk-max-delete |
Number (1-200) | Configurable maximum items per bulk delete operation |
bulk-max-update |
Number (1-200) | Configurable maximum items per bulk update operation |
None of these values constitute personal data. They are configuration identifiers.
| Key Pattern | Content | Lifetime |
|---|---|---|
csv-download:{uuid} |
CSV export content | 10 minutes, single-use (deleted after download) |
user-scan-setup-cache |
Cached application roles and org products | 5 minutes, auto-cleaned after scan completes |
pgm-groups-cache |
Product group mapping scan progress | 10 minutes, auto-cleaned after scan completes |
nonce:{uuid} |
Consumed single-use token for replay protection | Permanent but tiny (~50 bytes each, not personal data) |
CSV exports may temporarily contain user display names and email addresses from Jira’s own APIs. These are deleted immediately after download or after the 10-minute expiry, whichever comes first. Large exports are chunked across multiple storage keys, all of which are cleaned up together.
| Table | Content | Lifetime |
|---|---|---|
audit_log |
Admin actions: timestamp, admin account ID, action type, target account IDs (JSON), description, metadata (JSON) | Configurable retention (default 90 days, max 365 days) |
Activity Log entries record admin actions performed through the app (suspend, delete, remove access, board deletion). Entries are stored in Forge SQL (TiDB, MySQL-compatible) and written asynchronously via a Forge Events queue. The SQL database is provisioned automatically per installation and is region-aligned with the Jira site. Entries are automatically cleaned up based on the configurable retention period. On GDPR deletion request, all references to the requesting account ID are redacted from audit log entries in both SQL and legacy KVS storage.
| Key Pattern | Content | Lifetime |
|---|---|---|
audit-log-index |
Array of date strings with log entries | Legacy retention period |
audit-log:{date} |
Array of log entry objects for that day | Legacy retention period |
audit-log-retention |
Retention configuration (days) | Until changed by admin |
Legacy KVS-based audit data is retained for GDPR compliance (report and redaction) but new entries are written to Forge SQL.
The Jira Audit Log Analyser reads Jira’s built-in audit log records via the /rest/api/3/auditing/record API. This feature is read-only — it does not store, modify, or delete any audit log data. Audit records are fetched live on each search request and displayed in the browser. User display names and emails are resolved from account IDs via the Jira user API and cached in server memory (10-minute TTL) within the Forge container — this cache is ephemeral and not persisted to storage.
| Destination | Purpose | When |
|---|---|---|
| Jira REST API (within Forge sandbox) | All core Jira operations | Always — all features |
| Jira Agile REST API (within Forge sandbox) | Board listing, board deletion, filter usage detection | When managing agile boards or scanning filter usage |
Automation REST API (api.atlassian.com) |
Scan, enable/disable, delete, transfer automation rules | Only when using Automation Rules feature with per-session email + API token |
Teams Public REST API (api.atlassian.com) |
List, manage, archive/unarchive, delete Atlassian teams, bulk add/remove members | Only when using Teams feature with per-session email + API token (Basic auth, credentials never stored) |
| JSM REST API (within Forge sandbox) | Revoke portal access for JSM customers | When suspending JSM customer accounts |
api.atlassian.com |
Organization Admin API: user suspend, last-active dates, directories, groups, product access, teams | Only when admin has configured an Org API key |
No other external connections are made. No data is sent to TechClimbs servers, third-party analytics, advertising networks, or any other external service.
is_admin manifest conditionasUser() context so they are attributed to the calling administrator in Jira’s audit logsetSecret) and are never returned to the browser or included in logsX-Content-Type-Options: nosniff and sanitized Content-Disposition filenames.This privacy policy describes all data accessed, stored, and processed by the App. This policy is accessible within the App via the Privacy tab and as a standalone document.
The App implements Atlassian’s personalDataReport callback. When triggered for a given account ID, it returns any stored data associated with that user: (1) whether they configured the Organization API key; (2) a count of audit log entries in both SQL and legacy KVS storage that reference their account ID.
The App implements Atlassian’s personalDataDelete callback. When triggered for a given account ID, it: (1) removes the API key and the configured-by record if that user was the one who configured them; (2) redacts the account ID from all audit log entries (both SQL and legacy KVS) where it appears as either the performing admin or a target. CSV exports are temporary and auto-deleted. Uninstalling the App removes all Forge storage data (KVS and SQL) automatically.
User data (names, emails, group memberships) is always fetched live from Jira’s APIs and never cached permanently. Changes made in Jira are reflected immediately in the App.
The App stores only configuration identifiers and one encrypted credential. No user personal data is persisted. Operational data is held in browser memory during the session only.
The App does not share, sell, license, or transmit user data to any third party. No data leaves the Atlassian cloud environment except for calls to Atlassian’s own Admin API (api.atlassian.com).
The App is accessible only to users with the Jira ADMINISTER global permission or members of the jira-administrators or site-admins groups. The Atlassian Forge platform enforces the is_admin condition at the module level, hiding the App from all non-admin users. Every backend function additionally performs server-side admin verification that cannot be bypassed.
For privacy inquiries, data requests, or questions about this policy:
We may update this privacy policy to reflect changes in the App’s functionality. Significant changes will be noted in the App’s changelog. The “Last updated” date at the top of this document indicates when the most recent revision was made.
Last updated: 17 May 2026