It seems (as mentioned here as well) that clicking “Marketplace apps” in the settings menu now redirects to the admin.atlassian.com “experience”. However, how would an admin then reach the jira:adminPage module? It seems there is the option to use the three dot menu to if the “configure” or “gettingStarted” page is defined, but if this is not defined, there is no way to reach the admin page? That seems… bad?
In addition, the list on admin.atlassian.com is extremely unfiltered and showing stuff like “Automation for Jira”, which is some system stuff which is … uninteresting? For us, after installing an app, it’s not even on the first page, which makes getting to the admin page sooo much harder. Can you filter the list for Marketplace apps at least, if this navigation path is taken? Also, can we expose links to the settings in the detail pages of the app somehow? The “…” menu is really hard to discover. All of this feels kinda unfinished and hard to explain for new trials & onboardings…
Suggestions welcome. Also, please use it to point out specific gaps.
I believe there is an effort to try to better bridge from the install flow to admin configuration. In the interest of turning this thread towards something constructive, could I ask folks on this thread to propose some solutions? What kinds of “hooks” could the UI provide to drive admins to config and (separately) users to onboarding? How would the UI balance the needs to drive both, with the case when apps are installed in bulk (eg during cloud migration, sites often get a lot of apps installed in bulk)?
I think the issue that people are finding is that the way that the admin page that was not tagged as useAsConfig or useAsGetStarted was accessed previously is suddenly not available.
The GitHub README says:
the plain entry (no useAs property) appears as a sidebar navigation item
but the sidebar that showed the apps and therefore this page is no longer shown when you go to the same location as before.
It would be good to know if this is an intentional change?
It’s likely that the use-case for our apps would mean changing them to use useAsConfig though that’s not true currently.
An unfortunate side effect of this change is also that Jira admins cannot get to the settings anymore, but you’d have to be a site admin now. Our Jira admins do not necessarily have site-admin permissions, so there is no way for them to get to the app settings anymore. I’d strongly recommend rolling back this change.
This is the first time in years that I’ve been digging into the config options so perhaps I misunderstood your original post. If you think this is a straight-forward matter of a breaking change, then it seems appropriate to report as a bug to developer support:
@ibuchanan I think this proves the point that the Atlassian Marketplace partner community is trying to make.
You can’t actually go to config-lifecycle-admin-page directly. You need to go to config-lifecycle-configure-page or config-lifecycle-get-started-page first, and then navigate to the side bar to get to config-lifecycle-admin-page.
Another way to reach the app settings is by adding a jira:globalPage or jira:projectPage module. These modules have a tripple dot menu with “App Settings”.
This means that an app requires an jira:globalPage, jira:projectPage or a jira:adminPage with useAsConfig or useAsGetStarted in addition to the jira:adminPage used for app settings to allow users to get access to these modules.
In addition, having to navigating to the app settings through useAsConfig or useAsGetStarted pages not only includes 3-4 clicks more clicks, it is also confusing (because I don’t want to go to get started or configure, I want to go to the admin page). It also introduces a new constraint, as this path requires users to have site-admin rights to be able to access the Connect Apps page.
Not being able to directly navigate to application settings without requiring a jira:globalPage, jira:projectPage or a jira:adminPage module with useAsConfig or useAsGetStarted (and sub sequentially site-admin rights) is a regression and should be considered a bug.
Atlassian replied to my support ticket by creating the ticket linked above. There was also this note:
I request that you click This affects my team for the bug and add yourself as a watcher to track its status moving forward. You can provide any feedback you have in the comments. This helps us understand the impact it might be having on you and other customers.
So, please consider voting for a bug fix and adding a comment. Currently, it is rated a Low Priority bug, and they seem to consider bookmarks or navigating through admin.atlassian.com as reasonable workarounds.
I’m sure Atlassian has reasons for this specific change (I hear some overall UPM sunsetting); and hesitating to revert/fix this may also have reasons. But stepping back a bit, I can’t help but see this as an example of Enshittification: UX is worse, permissions required are higher, communcation/notice was short to non-existent (or did I miss anything?).
I encourage Atlassian to learn from this, so as to not – one day – be added to the long list of examples on the linked Wikipedia article above. I don’t intend this in a mean way; I just see a downward trend in regards to quality, and sincerely hope that Atlassian (together with the ecosystem, where sensible) finds ways to reverse this trend.
We’ve been hit by this as well. Our Forge apps rely on jira:adminPage for configuration, and since UPM was removed from canary instances, our admins have completely lost the ability to navigate to those pages through the Jira UI. The only option right now is sharing direct URLs manually, which is obviously not a sustainable workflow.
What’s particularly frustrating is that a change of this magnitude — effectively breaking the entire discoverability of Forge admin pages — was rolled out without proper testing or even a migration path. There was no deprecation notice, no alternative UI entry point provided, and no documentation update. This is a production-facing surface that app developers and their customers depend on daily.
A few things we’d really like clarity on:
Is there a timeline for restoring navigation to jira:adminPage from within Jira’s UI?
Will the new admin experience atadmin.atlassian.com be updated to surface Forge admin pages alongside connected apps?
Is there a recommended workaround beyond manually constructing deep links (/jira/settings/apps/{appId}/{envId})?
We understand that UPM deprecation is part of a larger platform shift, but breaking existing Forge extension points without a ready replacement is really not acceptable. Would appreciate an official response on the expected timeline and the planned resolution.
