We’re introducing support for multiple field contexts per project in Jira Cloud. This allows more than one context to exist for a single project across different issue types, and multiple default values to be set for different issue types within a single context.

As part of this change, the existing REST APIs for managing context default values are being deprecated and will be replaced by new APIs that support multiple default values.

Deprecated APIs:

• Get custom field contexts default values

• Set custom field contexts default values

Deprecation Timeline:

• July 2026: New default values REST APIs introduced. Existing "Get" API will return an error for contexts with multiple defaults; "Set" API will override all issue types in a context.

• October 2026: Existing default values APIs will be removed.

What you need to do:
If you use the affected APIs, plan to migrate to the new REST APIs before October 2026.

You can now nominate genuine migration blockers or major customer‑impact risks via the “Request review” flow on FRGE issues.

This flow will allow us to triage and assess requests to address remaining blockers to Forge migration before Connect end of support in December 2026. We’ll review requests over 3 monthly cycles, then freeze decisions.

Please review for existing tickets before creating new FRGE tickets.

Effective March 2, 2026, we are starting the phased enforcement of points-based quota rate limits for Jira and Confluence Cloud REST APIs. The rollout will begin with a small percentage of apps and gradually expand over several weeks, allowing us to closely monitor progress and minimize any disruption. API requests will start consuming points based on the work they perform, with app-level quotas applied consistently across two tiers:

1. Global Pool (Tier 1)

2. Per-Tenant Pool (Tier 2)

All Forge, Connect, and OAuth 2.0 (3LO) apps are in scope. API token-based traffic is not affected. The vast majority of apps are already operating well within these limits and will not be affected.

• To learn whether points-based quota enforcement has started for your app, inspect your API response headers. Quota-related headers with a Beta- prefix (e.g., Beta-RateLimit-Policy: "global-app-quota") indicate enforcement has not yet begun for your app. When enforcement begins, these transition to their non-prefixed equivalents (e.g., RateLimit-Policy: "global-app-quota").

• Jira REST APIs use multiple rate-limiting systems (quota, burst) that are transitioning to a unified structured headers(Beta-RateLimit, Beta-RateLimit-Policy)independently. The Beta- prefix on a header indicates that the system has not yet transitioned to production for your app. Use the policy name in the header (e.g., "global-app-quota" or "tenant-app-quota" for quota and for burst"jira-burst-based" ) to identify which system a header belongs to. Additional rate limit policy transitions to this unified header will be announced separately.

• We plan to discontinue sending quota rate limit values via the X-RateLimit-* headers in the future. A timeline will be published separately.

For full details on how points are calculated, quota tiers, unified header format and values, and best practices for handling rate limits, please refer to:

• Jira Cloud Platform rate limits

• Confluence Cloud rate limits

Following this deprecation announcement on Feb 17, 2026, the Connect Inspector Service is now decommissoned.

We recommend migrating to Atlassian Forge for a more robust Events model, as Atlassian Connect will reach end of support in December 2026.

Developers who still need similar functionality can use the open‑sourced version of the tool.

We are introducing baseline security requirements for Atlassian Government Cloud (AGC) apps, which will take effect on Mar 31, 2026. If you have any questions regarding these new standards, please contact us here: https://ecosystem.atlassian.net/servicedesk/customer/portal/34/group/109/create/579

We’re also publishing our annual update to the general Cloud App Security Requirements for 2026, which includes new provisions for AI security, data protection, and supply chain security. See More details for highlights on this update.

We’re introducing display condition support to the following Jira Service Management (JSM) Forge portal modules as a preview release:

• Portal footer

• Portal header

• Portal profile panel

• Portal request create property panel

• Portal request detail

• Portal request detail panel

• Portal request view action

• Portal subheader

• Portal user menu action

For these JSM modules, Forge apps can now declare displayConditions in the app manifest and have them evaluated by the host, consistent with how display conditions work for Jira and Confluence Forge modules today.

For further details, see the documentation here.

We've introduced two new components to UI Kit, now available in Preview: AtlassianTile and AtlassianIcon. Use these components to display Atlassian object type icons—such as stories, tasks, epics, blogs, and more—with consistent styling that aligns with the Atlassian Design System.

Both components provide fixed color, size, and styling options for Atlassian object types. Any updates to icon or tile styling in the Atlassian Design System are automatically reflected in your app.

For implementation details and examples, see the Atlassian icon and Atlassian tile component documentation.

The Connect Inspector service is moving to open source and also being deprecated. This service will no longer allow the creation of new temporary apps. Already registered temporary apps will stop recording new events, and old events will be deleted. Any apps already installed on developer sites will not be uninstalled.

We’ve added a new rovo.isEnabled method to the Forge UI bridge API. This method returns a boolean indicating whether Rovo is enabled for the tenant. You can use it alongside the existing rovo.open method to conditionally invoke Rovo only when it’s available.

For more information, see the updated documentation for the Rovo bridge methods.

We've added optional height and width properties to the Frame component in UI Kit. Apps can now set explicit dimensions in pixels or percentages, instead of relying on automatic resizing. This gives you more control over your app's layout.

For more information, see the updated documentation for the Frame component.

We've updated the behavior of the Create work type API. Previously, creating a work type automatically added it to the Default Work Type Scheme. This is no longer the case.

What's changing

• Creating a work type no longer automatically associates it with the Default Work Type Scheme

• You must explicitly associate work types to work type schemes using the Associate work type to a work type scheme API

What you need to do

If your integration relies on newly created work types being automatically available in the Default Work Type Scheme, update your code to explicitly associate work types after creation:

1. Create the work type using the Create work type API

2. Associate the work type to the desired work type scheme using the Associate work type to a work type scheme API

This change is not backward-compatible. Integrations that relied on automatic association may need updates to ensure work types are properly associated with schemes.

For more information, see:

• Work types in the Jira Platform REST API documentation

• Work type schemes in the Jira Platform REST API documentation

• Community post: Project fields association improvements for additional context

Related: CHANGE-2527 (deprecation notice)

Rollout : IN PROGRESS

This change log ticket is a followup to https://ecosystem.atlassian.net/browse/CHANGE-2527 (where we announced a deprecation whereby all new fields now needed to be added to projects explicitly when created via API).

• Create custom field: will no longer implicitly associate the field with all projects. It needs to be associated with the required contexts using the Create associations API.

We've updated the behavior of the Delete work type scheme API. Previously, you could delete work type schemes even when they were associated with projects. This is no longer allowed.

What's changing

• Work type schemes that are associated with one or more projects can no longer be deleted

• The Delete work type scheme API will return a validation error if you attempt to delete a scheme that is associated with projects

What you need to do

If you need to delete a work type scheme that is currently associated with projects, you must first reassign all projects to a different scheme:

1. Use the Get work type scheme API with the projects expand and id query parameter to get a list of projects associated with the scheme you want to delete

2. Use the Assign work type scheme to a project API to reassign all associated projects to another work type scheme

3. Once all projects have been reassigned, you can delete the unused scheme using the Delete work type scheme API

This change is not backward-compatible. Integrations that attempt to delete work type schemes associated with projects will now receive validation errors and must be updated to follow the migration steps above.

For more information, see:

• Work type schemes in the Jira Platform REST API documentation

• Community post: Project fields association improvements for additional context

Related: CHANGE-2527 (deprecation notice)

We're introducing new Beta rate-limit headers on Jira and Confluence REST APIs for points-based quota limits. These headers follow a unified, structured model aligned with standards on rate-limiting headers. They are informational only, they do not trigger enforcement or throttling. They are additive, and existing X-RateLimit-* headers continue to be returned.

• Beta-RateLimit-Policy – policy definition

  • A static header that describes the rate-limit policy applied to the request.

Example: Beta-RateLimit-Policy: "global-app-quota";q=65000;w=3600

• Beta-RateLimit – per‑response usage

  • A dynamic response header that provides usage signals for applicable rate-limit policies

    • Example: Beta-RateLimit: "global-app-quota";r=13000;t=600

When these two headers are returned without the Beta- prefix (RateLimit, RateLimit-Policy), points-based quota limits are actively enforced, and requests may be rate limited. For points-based quota enforcement, only RateLimit and RateLimit-Policy are used , the existing X-Beta-RateLimit-* and X-RateLimit-* headers will not be used. Standard HTTP headers such as Retry-After continue to apply where relevant.

For full details, including policy definitions and usage semantics, see the Jira Rate Limiting documentation here https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ and Confluence Cloud Rate Limiting documentation here https://developer.atlassian.com/cloud/confluence/rate-limiting/

We have increased the workflow history storage period from 28 days to 60 days.

For more information, see the API documentation for List history for workflow and Read specific workflow version.

Additional Notes:

• Workflow data from before Oct 30, 2025 remains unavailable as it predates this feature.