Can individual users opt in to the new navigation without admins turning on preview?

[Alvin Rodis]

Hello - I'm looking for clarity based upon THIS article. We have a Premium subscription to Jira and JSM and Standard for Confluence. Prior to the rollout of the new navigation by Atlassian, can individual users enable the new navigation to test for themselves?

I realize that as an admin I can turn it on for the entire instance, but I am not looking to do that at the moment. In working on our rollout comms plan we want to have users enable it for themselves if they'd like without turning it on for the entire instance.

Bottom line...can users enable the new navigation for themselves (Jira/JSM/Confluence) prior to the Atlassian rollout without the admin turning it on for the instance? Thank you!

[Martin Flury]

very simple, NO.
Only Admin can turn it on for themselves.

Normal user do not have access to the new navigation.

You could take some key users in the admin group temporary, but I'd be very careful with that!

[Alvin Rodis]

@Martin Flury  - thank you

[Gregg Brown]

Admin can turn it on for themselves or for everyone. When turning it on for everyone, any user can turn it off temporarily until the scheduled rollout time for that instance occurs—at which time it will be turned on for everyone who had turned it off.

Have you considered using your sandbox environment to turn it on in so that anyone can play around with it without it affecting production environment?

[Alvin Rodis]

@Gregg Brown - thank you

[Tosha Liveoak]

Hi, @Alvin Rodis , Unfortunately, only admins can turn on for themselves or for all users in the instance. That's consistent with Jira, JSM, Confluence, Atlassian Home, and Jira Product Discovery. Once you turn it on for your whole instance, individual users can turn it back off temporarily until Atlassian forces the new nav.

[Alvin Rodis]

@Tosha Liveoak - thank you.

[Mark B Wager]

Hi Alvin

Currently, in my sandbox testing, when I turn it on for all users, it defaults to ON for everyone (i.e., turning it ON) with an ability for users to toggle it OFF. This is fine for the sandbox I suppose, but NOT good in production. I'm asking that Atlassian lets users Opt IN at their own pace. 

Many of us seem to agree, we want a SOFT LAUNCH giving our users time for communication and opt-in. We want them to try it —> but by giving them the control to turn it ON (and Off) themselves for their own testing. 

I'm advocating for setting the initial individual DEFAULT to OFF when the "Enable for Everyone" button is clicked. (Essentially turning on the ABILITY to Opt-IN, but not forcing it on them at first.)

Hope this helps.

Mark

[Alvin Rodis]

thank you

[Gregg Brown]

That sounds like an administrative nightmare. As an admin, I want to know what experience my users are on so I don't have to have another layer to solving their issues. And I want control of that, not them. The sandbox is there for them to get used to it at their own pace before I turn it on for them in production. Email communications and office hour meetings/demos are provided for them to attend prior to it going live in production. If they aren't ready by time the rest of the org is ready for it, then tough luck. I'm not going to try to assist my users in a situation where half of them are on one experience and the other half aren't because they didn't want to accept change. 

[Darryl Lee]

Hi @Gregg Brown - I respectfully disagree.

People who OPT-IN to a new UI experience are self-selecting to "try the new thing". They're motivated to figure it out themselves. This is how I suspect that Atlassian got their < 3% opt-out rate during their EAP and Beta programs for the new UI. Of course those people stuck with the UI. They CHOSE to be testers for it.

So I don't think they're going to be generating a lot more work for you.

And the people who don't opt-in before the deadline? Well, yes, as you say, I don't have a lot of sympathy for them, but I believe that many of them, if they go back to the emails and see that they could've opted-in at any time prior to the deadline, will very likely say "Oh crap, yeah, my bad. I missed those emails. I could've switched over myself earlier."

IN CONTRAST, what I predict will happen is that yes, people will ignore the emails/Slack messages/signage/demos that we will also send out ahead of time.

But on the day we cutover, they're going to scream bloody murder. And they'll say "Why are you FORCING this on us?"

It's a matter of perspective (and frankly psychology) that was expressed well by Dennis Walsh regarding how they rolled out the Nav change of 2020:

I appreciate the statement that "We are also putting you in control of this change. Once your instance receives the new navigation, each of your users will be able to switch over to the new navigation on their own timeframe."  These changes look promising, but users still like to at least feel like they're in charge of their environment.

This is much better than the "just get used to it" approach used by certain "other" software companies (which shall remain nameless) who simply force-feed all of their "enhancements" on their users in one swoop, leaving the users either powerless to undo things, or -best case- forced to flail about and try to figure out on their own how to get their interface back to the way they want it.

[Gregg Brown]

While I understand your intent of giving users the choice, I think you're missing some key points on how doing so burdens admins. Particularly that as the admin of the tool, I need the rollout to be in my control. Otherwise I myself may not have had the time to check out the changes prior to a hypothetical time that Atlassian would let any one of my users turn it on. This means:

1. I'm not yet in a position to properly help them with issues they may have.
2. I've not yet updated documentation for the new experience so they can self-serve any issues they may have.
3. I now need to have documentation that has "Depending on which experience you're on..." flows in it. Whereas with a clear changeover point that I'm in control in, I can just prepare documentation for the new experience in the background and switch it all over with the rollout. 
4. I've not had the time to prepare comms and training for the new experience.
5. I will need to be moving myself back and forth between experiences to make sure I'm supporting my users accurately. 

In contrast, when I have control of the changeover, I can quietly prepare everything in the background and then make a clean, well-supported switch for everyone at once.

I’m not opposed to gradual rollouts in principle, but without admin visibility and control, opt-in becomes a burden. It fragments the environment, increases support overhead, and makes training and documentation inconsistent. These kinds of changes need coordination, not surprise adoption.

[Darryl Lee]

Hey Gregg - we're actually not that far apart.

I agree with you 100% that admins should have control over when the new UI is rolled out. I'm really glad that Atlassian has let us do this.

Yes, I want to be able to prep docs, send notifications, and declare that on THIS DATE there is no going back.

But I ALSO want to say: "ON THIS DATE, the new UI is available, and you can start cutting over NOW."

So what I want, which is what I thought I clarified is that Atlassian let us ENABLE this change on our own timetable, but not making us, as you put it, force a "surprise adoption" on our users. (Yes if they'd been reading their emails/Slacks/physical signage they should not be surprised, but still.)

Atlassian has the technical ability to let us choose how to roll this out, as me and other Admins are able to "switch over" early.

I just want that to be an option for users as well.

Instead of just this:

I'd simply like this an additional toggle:

Enable for everyone else ( )

Users will be able to switch over to the new navigation on their own timeframe (until the automatic roll out at the end of July)

You'd still have your button (which would force that toggle on).

And I'd be able to choose when to flip the toggle.

I'll still have time to do all the documentation, send emails/Slacks, and make signs before then. But my users won't feel like the decision was PUSHED on them.

[Darryl Lee]

Alas @Alvin Rodis the answer is currently NO. I asked the PM why over here.

I made this request way back in March. I see that @Dominik Březina, @Brad Hosking, @Mark B Wager , and @Ariel Kauan asked for it since "opt-in" was announced.

Asking @Aditi Dalal, @Brett Uglow and @Varsha Patel here if there's some technical reason that they couldn't enable opt-in for EVERYONE, not just Admins.

Because if Atlassian can enable Admins to individually turn on the new nav for themselves, then it seems like the pieces are there to let Users also do this.

The only response I ever got about this seemed to misunderstand what we were asking for:

Based on our research with admins from late 2024 to early 2025, we found that managing bespoke workflows at the user level becomes increasingly challenging for admins of the organization. To address this, we're giving admins control over whether to move their users to the new navigation starting in mid-April 2025 before we enforce the transition as per our rollout.

To clarify. We don't want the control to force the UI on our users. We want to put that control in the hands of our users. As it was done (very sucessfully) in 2020:

https://community.atlassian.com/forums/Jira-articles/A-better-navigation-for-Jira-Cloud-is-coming-soon-available-now/ba-p/1216077

Specifically this comment from @Dennis Walsh :

I appreciate the statement that "We are also putting you in control of this change. Once your instance receives the new navigation, each of your users will be able to switch over to the new navigation on their own timeframe."  These changes look promising, but users still like to at least feel like they're in charge of their environment.

This is much better than the "just get used to it" approach used by certain "other" software companies (which shall remain nameless) who simply force-feed all of their "enhancements" on their users in one swoop, leaving the users either powerless to undo things, or -best case- forced to flail about and try to figure out on their own how to get their interface back to the way they want it.

[Alvin Rodis]

Thank you for this info

[Mark B Wager]

I'm disappointed to hear that Atlassian won't set the default to allow "Turning it on" (meaning to turn ON the ABILITY for users to turn it on) for themselves.

Microsoft has a "Try the New Outlook" toggle switch right on the page. Users can turn it ON or turn it OFF. Great way to have users try a change at their own pace. I'd say Microsoft is a HUGE, successful company -- Atlassian, might be worth taking a page from their playbook for these HUGE feature roll-outs.

I guess I'll just put together MORE instructions.

I hope this all goes well. 

Mark

[yqiao]

Hey in case people don't know how to bring the Navigation back to the old version:

1. Go to Settings menu on the top navigation
2. Click General Settings
3. Scroll down and head to the Jira Lab section, we will see a toggle like

[Darryl Lee]

Hi @yqiao - while you are correct that users (if they are on Standard, Premium, or Enterprise plans for Jira) can revert to the old version of Navigation, it's important that they know that they can only do so temporarily. As the official timeline says:

Standard plan

For Jira and Atlassian Home, users can still turn off the new navigation only for themselves till the end of May 2025. This will not affect anyone else on the site.

Premium and Enterprise plan

For Jira and Atlassian Home, users can still turn off the new navigation only for themselves till the end of July 2025. This will not affect anyone else on the site.

And that by the End of July 2025:

All users of all plans are on the new navigation with no ability to turn it off.