Work Item View 2.0 for Ecosystem Partners

[AhmudAuleear]

Hey Everyone,

We are redesigning the Jira Work Item View, the screen teams use every day to view and update their work, and it is now targeting GA in the October Jira release.

Background

The Work Item View is the primary surface where customers do their daily work, and where they discover and engage with Marketplace apps. The work view can be tested now via the admin beta settings. More details of the changes can be found here: Community Post

The problem we identified

Over time the Work Item View had become cluttered and harder to use. Core actions and information were not prominent enough, common tasks took too many steps, and the layout did not scale well as more elements (including app entry points) were added to the page. The result was an experience that felt heavier than it needed to be for everyday work.

How we solved it

We refreshed the visual experience: a clearer layout, core actions and information front and centre, and fewer steps to get things done, so every team finds Jira easier to use. The change went through Dogfooding and an EAP with positive signal including ecosystem partners. It is now an opt-in Open Beta, with users able to switch back to the classic view at any time.

Importantly, this is a UI and experience uplift, not a change to how Jira works. The data, structure, and configuration behind work items are unchanged.

Impact to Ecosystem

The visual elements have been refreshed, but underneath everything works the same. Your apps continue to work exactly as they do today.

• Extension points and modules: Forge and Connect modules continue to function. There is no module deprecation and no required code change to keep working.

• Field IDs, data, and configuration: unchanged, so reporting, automations, and integrations that depend on them are unaffected.

• App placement and discovery: what changes is the visual presentation and placement of app entry points in the new layout. Early partner-relevant feedback flagged that app and toolbar icons can feel too small, which risks reducing app discovery. We are actively working on this and want partner input on the fix before we scale to GA.

We recognise that vendors have built apps that add significant value to Jira’s ecosystem, and we are committed to ensuring this change does not unintentionally disrupt that value. We invite you to test your apps in the new Work View during the Open Beta and share any feedback on rendering, placement, or discoverability so we can prioritise them.

[emrekaraduman]

Hi @AhmudAuleear

Thanks for opening this up for partner testing. We ship a Forge app with a number of jira:customFieldType modules and enabled the Open Beta to test them. Four issues below, all reproduced on the same work item and confirmed by switching the same user back to the classic experience, where none of them occur.

Our modules declare issue-view on both view.experience and edit.experience, and every edit entry point sets isInline: true.

1. Empty custom fields don’t render their empty state on the view screen

A field with no stored value renders nothing next to its label — neither the app’s view entry point nor Jira’s own placeholder. Fields that do have a stored value render normally.

2. view.value.function is not invoked

The docs say the value function is computed when the user opens the issue page, and that Jira persists the result. On the modern view it never runs: fields backed by a value function keep a null stored value when read back over the REST API. Loading the same work item once in the classic view populates all of them immediately. Our value functions derive their result from the work item and always return a value, so null isn’t something they can produce.

This is also what makes (1) permanent for read-only derived fields — the value function is the only thing that would ever give them a value, and they expose no edit experience to fall back on.

3. Reaching edit mode takes two clicks

The first click on a field opens the view experience, not the editor. The second click opens the editor. When the field already has a value and is already showing its view, the first click still only re-renders the view, and only the second click opens the editor.

4. Blur doesn’t trigger submit in edit mode — only Enter does

The docs are explicit that blur is a commit trigger:

In issue view, the onSubmit function in the CustomFieldEdit component will be called on blur events, “Enter” key press, or on clicking confirmation action button, so you can place the submit logic there.

On the modern view onSubmit is not called on blur: the editor closes, the value is discarded, and no error is shown. Pressing Enter in the same field commits normally.

For Custom UI edit experiences this leaves no working path at all: clicking anything inside the app moves focus into the iframe, which blurs the host field and closes the editor, so the app can’t be interacted with.

With GA targeted for the October release, we’d like to know whether these will be fixed, or whether there is a migration path we should be following instead.

Also filed as FRGE-2275: https://ecosystem.atlassian.net/browse/FRGE-2275

[tbinna]

@AhmudAuleear, some of our customers are reporting the same issue with app custom fields, as noted above. The first screenshot below shows custom fields (jira:customField) in the new view; they appear empty and grayed out, with a cursor: not-allowed style when hovered.

Could you please indicate if Atlassian is aware of these issues?

[emrekaraduman]

Hi @tbinna

I created issue to atlassian for this problem. Jira. Can you please vote it?

[AhmudAuleear]

Hey Team,

We are actively looking into these issues. Once we have a fix and timeline we will respond.

[tbinna]

Noticed today that something outside the app iframe in the issue context module is adding padding around the app when the new work item view is activated.

Can this please be fixed?

PS: I can’t seem to tag AhmudAuleear since the account is suspended, so I hope someone from @atlassian sees this post.

[NatashaRoumanoffClou]

Hi team,

I’m testing our Forge app in the new work item view ahead of the late-October rollout. Two parts of our jira:issueContext panel that render in the classic view don’t appear in the new one. I’d like to confirm whether this is a known gap, a bug or an intended change, because the answer decides whether we rework our UI before GA.

Our app declares one jira:issueContext module (Custom UI) with a title, a label and dynamicProperties pointing at a function that returns a count badge. In the classic view the group header shows the title in bold with the label beneath it in grey, and the badge appears in the header while the group is still collapsed. That collapsed badge is the main reason the panel exists: it tells an agent there is something to look at before they expand anything.

In the new view (tested 12 October 2026 with the “Modern work item” beta enabled, on work items with qualifying attachments), the panel moves into the new “Apps” section of the sidebar, and its header shows the title only. The grey label text doesn’t render, and no badge appears in the header, either collapsed or expanded; the badge is absent from the DOM, not merely hidden. Expanding the panel renders our Custom UI body correctly, so the module itself works. I haven’t yet confirmed whether the dynamicProperties function is invoked in the new view at all.

Steps to reproduce:

1. Install a Forge app with a jira:issueContext module that declares both label and dynamicProperties returning a badge.
2. Open a work item in the classic view and confirm the badge and label appear in the collapsed group header.
3. Enable Settings > System > Beta features > Modern work item, and reload the same work item.
4. Open the Apps section in the sidebar: the module’s header shows the title only, with no label and no badge.

The attached screenshot shows step 4. The title truncation in it comes from the development environment’s DEV label and isn’t part of this question.

My questions:

1. Is dynamicProperties (and the badge it returns) supported for jira:issueContext in the new view? If so, is this a known issue, and is a fix planned before GA?
2. Is label intentionally no longer rendered in the Apps section?
3. If both are intentional, what is the recommended way for a context panel to signal a count or status without the user expanding it?

A related observation: jira:issueActivity tabs now appear as options in the Activity dropdown, which defaults to Comments, rather than as visible tabs. Is there any way for an app’s activity view to be discoverable without opening that dropdown, and is the dropdown’s order or default configurable?

This may be connected to the 5 October report in this thread about extra padding around issue-context app frames.

Thanks,
Natasha

[NatashaCloudscript]

Follow-up to my post above, with more detail after instrumenting both views on the same work item:

1. The dynamicProperties function is never invoked in the new view. In the classic view, loading the work item sends a useDynamicPropertiesMutation request for our jira:issueContext module, and our function logs its call in forge logs. In the new view, on the same work item and with the same user, there is no useDynamicPropertiesMutation request at all, and the function logs nothing. That holds whether the Apps section is collapsed or expanded at load, and after expanding the panel. The panel body itself loads normally through its own resolver. So this looks like the new view not requesting dynamic properties for context panels, not a rendering problem.
2. Correction to my earlier note about jira:issueActivity. At a normal desktop width, the app’s activity view sits under an “Apps” menu button at the end of the activity tab row, not in the All/Comments/Work log dropdown. That dropdown only appears in a narrower layout. My question still stands: is there a way for an app’s activity view to be discoverable without opening a menu?