Jira Dashboards: upcoming changes and new Forge dashboard:widget module general availability

[AllanahMiller]

Hello, developer community!

We are sharing an update on Jira Dashboards, the new Forge dashboards:widget & dashboards:backgroundScript module and what it means for Marketplace partners and developers who build Jira dashboard gadgets today.

The overview:

• As previously communicated here, Introducing Atlassian Home Dashboards! & in our Jira changelog, our new Forge module & dashboards are rolling to general availability.
• Jira Dashboards are being upgraded over the coming quarters to a more modern, flexible dashboarding experience, with customer announcements and rollout beginning in the coming weeks.
• The rollout will start with customers having dual-create functionality to create a classic Jira dashboard or a new dashboard.
• Customer migration will be progressive, with cohorts that depend on Marketplace dashboard apps gated on partner readiness.
• Existing Forge modules jira:dashboardGadget and jira:dashboardBackgroundScript will be deprecated by 17 May 2027. Existing Jira dashboard gadgets will need to be migrated to the new module, for dashboard widgets to appear on the upgraded dashboard surface.
• Partner migration will include both code migration, supported by code mods, and data migration.

What is changing?

What’s changing for customers

Jira Dashboards are evolving into a modern, flexible analytics platform designed for richer layouts, interactive visualisations, stronger cross-product reporting, and future AI-powered insights where those experiences are enabled.

To ensure a smooth transition, the rollout begins with dual-create, allowing teams to explore the new upgraded dashboard experience alongside classic dashboards at their own pace without disrupting the dashboards they already use to run their work.

The transition will be paced across customer cohorts, ensuring teams that rely heavily on Marketplace dashboard apps are handled carefully and gated on partner readiness where needed, so critical third-party reporting experiences are not stranded during the migration.

What’s changing for partners

To power this new surface, the Forge dashboards:widget and dashboards:backgroundScript modules which have been in EAP since May of 2025 are now generally available. Providing the foundation for more interactive, flexible, and intelligent app experiences on upgraded dashboards.

Existing dashboard gadgets need to move to the new dashboards:widget standard.

Most importantly, customer rollouts will be paced to match partner readiness. Cohorts that rely on Marketplace apps will only transition once upgraded widgets are ready, protecting our shared customers and giving your team the runway to launch and validate with confidence.

Why are we making this change?

Jira Dashboards are a large and important reporting surface for customers. They haven’t kept pace with the rest of the Jira platform and we are upgrading them to support a more flexible dashboard experience, better cross-product reporting foundations, and future AI-powered insights.

For partners, this is not intended to be a like-for-like technical port only. Forge dashboard widgets can support richer configuration, interactive experiences, and structured data that can be used by Atlassian Intelligence when the relevant AI experiences are enabled.

What can the new Forge dashboard widgets do?

The dashboards:widget module lets you build interactive widgets that users can add to the new dashboard experience. Widgets can:

• Display custom data and visualisations
• Handle user interaction
• Communicate with background scripts
• Provide a dedicated edit mode for user configuration
• Contribute structured data to AI insights through the ai-context property, where available

Read the Forge dashboard widget module documentation to get started.

Example manifest

A minimal UI Kit manifest looks like this:

modules:
  dashboards:widget:
    - key: hello-world-widget
      title: Hello World Widget
      description: A sample dashboard widget
      thumbnail: https://example.com/icon.svg
      resource: widgetResource
      render: native
      resolver:
        function: widgetResolver
      edit:
        resource: widgetEditResource
        render: native
        resolver:
          function: widgetEditResolver

resources:
  - key: widgetResource
    path: static/widget/build
  - key: widgetEditResource
    path: static/widget-edit/build

functions:
  - key: widgetResolver
    handler: widgetResolver.handler
  - key: widgetEditResolver
    handler: widgetEditResolver.handler

The edit block defines the configuration experience users see when they customise a widget. The resolver functions connect the widget UI and edit UI to backend logic. If your widget exposes tabular data for AI insights, add an ai-context handler so Atlassian Intelligence can request structured data where that experience is enabled.

To get started, run forge create, choose a Dashboards template, then run forge deploy and forge install.

What this means for existing Jira dashboard gadgets

There are two migrations at play for us to consider here:

• Connect end-of-life migration: Connect apps are moving toward end of life, so app teams should plan and prioritise their migration to Forge across their Jira app experiences.

• Jira Dashboards upgrade: the dashboard surface itself is being upgraded. Dashboard gadgets will need to be migrated to the Forge dashboards:widget module to appear as supported widgets in the new dashboards experience.

If you own a Jira dashboard app or gadget today, you should audit your gadget usage and identify which experiences you plan to migrate to the new Forge module.

As you plan your migration, identify which saved configuration values, filters, project selections, and permissions your app needs to carry forward, and tell us where you need migration APIs or guidance.

We’re actively developing migration support to help you move existing Jira dashboard gadgets to the new Jira dashboard widget module:

• Migration skills and codemod
• Platform-assisted migration: You’ll declare which existing gadget modules each widget replaces. Where configuration transformation is required, you’ll implement a migration function in your Forge app. Jira will invoke it while migrating existing gadget instances in customer dashboards.

We’ll publish the final API, tooling and examples before migrations begin.

In the meantime, we recommend:

• Planning how the existing gadget view and edit experiences will work in the widget’s edit-and-preview panel.

• Starting development of the replacement widget.

We will not strand customers who depend on marketplace apps. The Jira Dashboards upgrade is being rolled out progressively. Tenants that depend on dashboard marketplace apps will be handled in dedicated cohorts and gated on partner readiness where needed.

However, once a tenant who doesn’t use any marketplace apps today is migrated to the new platform, access to legacy dashboards will be switched off. Any gadget that has not migrated to the Forge dashboards:widget module will become unavailable to those customers.

Prioritising your migration now ensures potential new customers have access to your app throughout all migration stages.

Timing

Deprecation and replacements

• Legacy module documentation
• New module documentation

FAQ’s

Will existing Jira dashboard gadgets keep working during rollout?

Existing gadgets will continue to be considered as part of the progressive rollout. Customer cohorts that depend on Marketplace dashboard apps will be managed separately and gated on partner readiness where needed.

Can partners support both legacy gadgets and Forge dashboard widgets during the transition?

Yes. If your app has customers on legacy Jira Dashboards and customers moving to the upgraded experience, you should plan for both experiences during the transition period.

Will customer layouts and gadget configuration migrate automatically?

Not automatically as partner-built Forge widgets. Review the configuration your gadgets store today and identify which values need an explicit migration path.

Where can partners get migration support?

Reply on this thread with blockers or reach out directly at amiller4@atlassian.com

How can we integrate with Chart insights?

Dashboard widgets can optionally provide a structured, tabular view of their data to Atlassian Intelligence using the ai-context property. This can power AI-generated insights for an individual widget and, where available, dashboard-level insights.

Availability note: the ai-context property is part of the dashboards:widget module, but the AI insights experience it supports is in an EAP, you can sign up for it here.

How can we integrate with Dashboard filters?

We are actively working to enable dashboard filter integration via Forge. We will announce its EAP in the coming weeks. Reply to this thread or contact amiller4@atlassian.com with requests or ideas for dashboard filter integration.

How to give feedback

Reply on this thread.

We know this is meaningful work for partners who build reporting experiences on Jira Dashboards. Our goal is to give you a clear migration path, avoid surprising customers, and work with you on the blockers that matter before customer cohorts move.

[aron.gombas]

It is about moving to Atlassian Home, which I consider a generic location not tied to any specific Atlassian app, but then the article specifically talks about Jira dashboards.

1. Will Atlassian Home provide gadgets also for Confluence? Bitbucket?
2. Can you develop a Forge gadget for Confluence? Bitbucket?

[BenRomberg]

@AllanahMiller thanks for engaging with the developer community on this migration! A few questions:

1. The new dashboard widget documentation still says “EAP”, has it been updated with the latest GA features yet?
2. Is it possible to interact with the Dashboard filters in the new Atlassian Home Rovo Home Dashboards yet? If not, is it planned to be able to do so from within Forge gadgets?

[nathanwaters]

Will existing dashboard-item properties be preserved during the migration?

You made a changelog and CDAC post but kept the docs outdated. I’d already submitted an ECOHELP. If others did too then it compounds the unnecessary bureaucracy.

Also why was this not made GA long before Forge EOS was announced? Partners do not want their time wasted by an endless migration treadmill.

[DanSparrow]

The docs indicate that the edit property is not required here. Yet if I try to deploy with a dashboard:widget without this property using v14.0.0 of @forge/cli I receive a dashboards:widget must have required property 'edit' valid-document-required error from forge lint.

We plan on migrating our jira:dashboardGadget modules but our gadgets/widgets are not configurable so we do not require an edit resource therefore this is a blocker for us. We did not have to provide one previously so please can we have some clarification on whether an edit property is actually required? If so, how are gadgets/widgets with no editable configuration expected to be declared?

[DanSparrow]

If dashboards:widget is now GA does this not mean that the respective widget (after a fresh forge deploy) should be accessible via Atlassian Home → Dashboards? Even if we as a partner have not opted in to the EAP?

Given:

The rollout will start with customers having dual-create functionality to create a classic Jira dashboard or a new dashboard.

Indicates that Jira sites may not have access to the new dashboard experience and the new widget(s) for a period of time. How can we start testing migration to this new GA module if we haven’t opted in for the EAP?

[AllanahMiller]

Hi Aron - thanks for flagging this.

• We are eventually replacing the existing Jira Dashboards, with the dashboards that were initially launched into EAP as ‘Home Dashboards’. (So instead of being in Home, they will be in Jira).
• Even though they will be in Jira, they do have ‘cross-app’ data, today they have Bitbucket widgets natively, though no Confluence data.
• Your forge widgets on these dashboards can contain any data that you’d like to present, from public Atlassian APIs or your own data sources. The data will be presented in the Jira UI, where the dashboards are.

[AllanahMiller]

Hey Ben - thanks for these callouts!

1. The documentation is accurate, we are working to get the ‘EAP’ label removed, but have run into a few delays, we expect it to be fully reflective within the next week.
2. It’s not possible yet, but it is about to land, I expect we will post another change-log and CDAC post late next week outlining the changes here.

[AllanahMiller]

@nathanwaters

Will existing dashboard-item properties be preserved during the migration?

Yes, they will be preserved.

Thanks for the feedback Nathan and understand the sentiment. We are working on providing a solid timeline and more details for the platform-assisted migration in the coming week. We are working as fast as we can to get this to you and all partners.

We are working to remove the ‘EAP’ label from the documentation.

[AllanahMiller]

Hi Dan - thanks for flagging and good catch. This is a miss on our side, we have created a ticket and are working to resolve this. I will loop back once we have fixed this.

[AllanahMiller]

Hi Dan - we are working on rolling out the dashboards in Jira to all tenants over the coming weeks, if you have the site URL’s of the sites you would like to be enabled, we can do this for you as a priority. Feel free to email me at amiller4@atlassian.com if you’d prefer!

[AllanahMiller]

Just wanted to follow up here.

While we are working towards a 100% rollout, you can automatically opt your site in by joining the Developer Canary program. Let me know of any questions/ concerns!

[RaimundasJuska]

We’ve ported one of our gadgets to dashboards:widget (custom UI). Three questions:

1. Live preview while editing - supported or planned? The preview pane only updates after Save. setPreviewConfig() from the edit instance does nothing (no error, no change).
2. Is displayConditions supported on dashboards:widget? Not in the docs. It deploys, but so does an invented property — that passed lint and server validation too.
3. extension.filters already arrives in the widget context. Can we build on it now, or wait for the filters EAP?

Minor: thumbnail accepts a resource: reference despite the docs requiring an absolute URL. Worth correcting — absolute URLs imply egress and cost the Runs on Atlassian badge (as ECO-912 for gadgets).

[DominikPatrzek]

Hi @AllanahMiller,

The new dashboards are already enabled on my site (dominiksite.atlassian.net). However, only Atlassian’s native widgets are available there. My app’s dashboards:widget doesn’t appear.

I then joined the Developer Canary program as you suggested and redeployed the app, but the widget still doesn’t show up (it has been a few hours).

Is there anything else I need to do on my side for my widget to show up? And do you have an estimated date for when Forge widgets will be available on all sites?

Thanks

[AllanahMiller]

Hi Dominik, this change is now rolled out to 100% so we expect this to be fixed for you now. Can you confirm?

If you are still unable to see your widgets here, can you email me at amiller4@atlassian.com so we can set up a time to troubleshoot?

Thanks!

[AllanahMiller]

Thanks Raimundas,

1. This should already work, can you try widgetEdit.updateConfig, then the widget in the preview pane should update with the draft config
2. We don’t support this, and it’s not currently on our radar to implement. Can you help me understand your use case yet?
3. Yes, you can use extension.filters now, the formal EAP will be coming this week.

Let me know if there’s anything else here!

[DominikPatrzek]

Hi @AllanahMiller,
I just checked and everything is working perfectly now. Thanks for the update!

[RaimundasJuska]

Thanks @AllanahMiller. On displayConditions - we had hasSoftwareAccess: true on one gadget (a velocity chart that needs boards and sprints), but on inspection we already handle the empty case in-widget, so this isn’t a blocker for us. Treat it as a nice-to-have for picker tidiness rather than a requirement.

[RaimundasJuska]

@AllanahMiller, we ran into a couple more issues when testing this — two questions on dashboards:widget with Custom UI:

1. Following up on the live preview answer — widgetEdit.updateConfig does update the platform’s copy, but with Custom UI the preview pane is our own iframe, so nothing re-renders our app. We’ve used @forge/bridge events.emit/on to push the draft config from the form iframe to the preview iframe, which works. Is that the intended approach for Custom UI, or is updateConfig expected to trigger a re-render there too?

2. Rejecting a save on invalid config. The widgetEdit docs (https://developer.atlassian.com/platform/forge/apis-reference/dashboard-bridge-apis/widget-edit/) say onProductSave should return “Config to save, or null/undefined to skip product save”. We tested this on a configured widget in development: returning null replaced the stored config with {}, which persisted across a reload — the configuration was lost rather than the save being skipped. Is that expected? If null isn’t the way to block a save, how should an app reject one when the config is incomplete or invalid — does throwing from onProductSave abort cleanly?

This second one is blocking for us. Our gadgets validate before saving and refuse the save when it’s wrong. On the classic surface that works because the gadget owns its Save button. On the widget surface the platform owns Save, so unless the app can reject it, invalid configuration gets stored and the widget renders broken with no way for us to prevent it.

[AllanahMiller]

Thanks Raimundas - here are our thoughts, happy to jump on a call or email chain if easier.

1. The recommendation is to use the hooks (if using React) useWidgetConfig useWidgetContext so they are auto-subscribed to changes. Otherwise, will need to use the events API like you mentioned and read updated data from view.getContext(). We can also provide an easier API for non-React subscription if you think it’ll be helpful, let us know!
2. For onProductSave, the recommended way is to reject/throw when there is an invalid config, so the drawer will not close and you can display a validation error. We’ll update the docs as it does sound a bit confusing, but returning null means clearing the save entirely (not skipping), and if you do want to skip, can also just return what was in the original payload, i.e.

widgetEdit.onProductSave(async (config) => {
  return config;
});