Skip to content

SYSTEM Cited by 1 source

Atlassian Jira Optimisation Tools

Atlassian Jira Optimisation Tools is a set of Jira Cloud admin experiences plus backend async workflows that help customers stay under the limits and guardrails Atlassian introduced as Jira scales to "100k+ users and beyond" (700 fields per space, 150 work types per space, 20,000 field options per field, 50 issue security levels per space, 50 grants per permission, plus limits around versions, workflows, components, and priorities). The tools sit alongside Site Optimiser (the admin dashboard surface that surfaces configuration issues across spaces) and consume reports produced by the pre-computation framework.

Architecture

For each supported entity type (today: fields and work types), every Optimisation Tool follows the same two-phase shape:

  1. Reporting — find opportunities to bring a space's data shape back under limits and guardrails.
  2. Remediation — apply safe, auditable changes based on those findings.

Reporting is async (workflow-orchestrated periodic pre-computation jobs) and per-space; remediation is on-demand bulk-action consuming the report; the report is the contract between the two phases.

The split is structural:

  • Optimisation tools (this system) own the product experiences and domain logic — what "unused" means for fields versus work types, which recommendations to surface, which actions to expose.
  • Optimisation platform (the pre-computation framework + workflow orchestration engine) owns the shared services and workflows that make them safe and scalable — orchestration, batching, retries, observability.

(Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Two-phase flow

Reporting phase

The platform runs *asynchronous jobs that scan Jira data for a given scope (for example, a space) using domain APIs. For work items, this can mean fetching keys from work items service; for configuration like fields or work types, we call the relevant services directly. (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Output: "a stored report describing how that space deviates from our limits and recommendations."

Remediation phase

Optimisation tools expose opinionated, pre-curated actions that consume the report and mutate configuration to reduce bloat:

  • Dissociating unused fields from screens / schemes.
  • Splitting field configuration schemes to disentangle shared schemes that have grown overloaded.
  • Cleaning up unused work types at the space scope.

(Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

All changes flow through Jira's existing safety nets and audit logs, so admins can see exactly what was done and, if needed, manually roll it back. See patterns/audit-log-as-rollback-substrate for the broader discipline.

Storage architecture

Optimisation Tools store pre-computed "usage" data for many Jira entity types (fields, options, roles, schemes, etc.) at scale. The data is:

  • Large — up to ~1M records per entity type, per tenant.
  • Read-heavy — queried often in reports and admin UIs.
  • Refreshed in batch — monthly / periodically, not in real time.

The two-layer storage decision:

  • Memcached for short-lived multi-step sharing inside a single job.
  • Jira relational database for persistent pre-computation, using a small set of generic "polymorphic" tables instead of one table per entity type.

See tiered state management for the broader pattern, and polymorphic usage tables for the multi-tenant DB-design contribution. The decision rationale is verbatim: "Naively adding one dedicated table per entity doesn't scale in Jira's multi-tenant architecture: a single new table becomes millions of tables across production, plus indexes and internal database objects." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Refresh strategy

Optimisation Tools rely on pre-computed reports about each space; reports become stale as spaces evolve, and recomputing every space on a fixed schedule is "extremely expensive at Jira scale." Instead the system uses utilisation-prioritised refresh: recompute reports only for spaces nearing limits (≈70% utilisation). To reduce the risk of acting on stale data:

  • The last pre-computation timestamp is shown in the UI alongside every usage report.
  • Admins can trigger ad-hoc reporting jobs for specific spaces / schemes whenever they want fresh data.

(Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Recoverability

The 2026-05-14 disclosure names a deliberate v1 trust posture:

  • Targeted, opinionated actions based on pre-computed reports — not a free-form bulk-edit tool.
  • All changes logged in audit logs, so admins can see exactly what changed and manually reverse or adjust configuration if needed.
  • Assisted rollback already exists; guided in-product rollback is on the roadmap as a future addition layered on the same audit-log foundation.

This is the canonical patterns/audit-log-as-rollback-substrate instance on the wiki: instead of building snapshot or transaction-based rollback infrastructure for destructive bulk operations, lean on the existing audit log and accept manual human-driven rollback as the v1 contract.

Operational outcomes

(Aggregate-only; no p50/p99, RPS, or per-space numbers disclosed.)

  • "Admins across organisations have removed tens of millions of unused fields and work types using these optimisation tools."
  • "Some customers have streamlined hundreds of thousands of fields and work types in a single day — a process that previously took weeks of manual effort."
  • "Optimisation tools enable vast majority of tenants to stay within the limits, including our largest enterprise customers."

(Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Seen in

Last updated · 542 distilled / 1,571 read