Tabs coming to Confluence

Hello everyone,

Today we’re announcing an upcoming feature that is coming to Confluence Cloud. We’re building a native tabs macro that will be available to users in the Confluence editor. We know this impacts some of you who have built tabs apps and have served customers’ content formatting needs for a long time. We want you to have a clear picture of what’s coming so you can plan your roadmap and keep delivering value beyond the experience we’re building.

What we’re building

  • A native tabs macro that can be inserted in Confluence pages and live docs
  • Users can add/remove/reorder tabs within the macro
  • Tabs titles will support emojis and background colors
  • Tab operations will be supported by Rovo / agents
  • Early release will support horizontal tab layout only, with vertical layout planned for a future release

Why we’re building this

Tabbed layouts are how many teams organize content like specs, runbooks and release notes, and this pattern shows up consistently in customer feedback as something Confluence needs to support natively in the editor. We are building tabs to meet our customers’ expectation for core creation and editing in a modern knowledge tool, including support for AI-assisted flows through Rovo and agents.

Timeline: We’re aiming to release tabs at the end of July / early August.

Confluence Tabs

We know this may be difficult news for partners who have invested deeply in tab experiences for Confluence. Our goal is to communicate transparently and keep an open dialogue with you as this work progresses. If you’d like to test the tabs feature once it’s available in early release, please join the Developer Canary Program. If you have questions or feedback, please share them in the comments. Thank you!

I know this is not going to change anything, but it has been said before and I will say it again: one of the reasons this ecosystem thrives and what makes it so special is because in the past, Atlassian has recognised the contribution of Marketplace Partners to the overall growth path.

As a result, whenever Atlassian decided to sherlock features previously provided by Marketplace Partners, it had the decency to buy the most popular app from the vendor. This happened most notably to GreenHopper, Confluence Analytics, Insights, ProForma, Automation and a few others. Those apps would then be turned into native features.

In addition, it was also beneficial for customers. It ensured that their content would be preserved. It relieved them from the difficult decision to either migrate, or continue paying a 3rd party for a feature that was natively available. This strategy perfectly aligned with a core company value.

For Atlassian, purchasing apps from partners does almost nothing to their balance sheet. For vendors, it makes all the difference between loosing their main income stream and having a golden parachute that allows them to find a new path. In some cases, these vendors decided to join Atlassian and continue developing the native feature.

I want to strongly encourage Atlassian to consider going back to this practice, not because it cannot create these features independently, but because of basic human decency.

The only thing that really surprises me is that, even though there are many known blockers or issues with Forge, resources are being allocated to things for which solutions already exist for customers.

Customers may now expect to have certain features available natively, which is a legitimate expectation. But again, if you derail your timeline for the Connect’s EOL, vendors are financially penalized because their apps aren’t yet fully on Forge, and you then allocate your resources to other things; this leads to frustration and mistrust.

And as far as transparency goes, if you don’t communicate these kinds of things until just weeks before release, then you’re anything but transparent with partners in your ecosystem.

Thank you for sharing this, @LauraMehrkens

Refined Macro Toolkit, together with other apps, serves tens of thousands of customers with tabs functionality, and we want to echo what others have raised here. Our concern is less about Atlassian building natively, that’s a reality we accept, and more about the timing and the broader context it sits in.

We have active, documented Forge migration blockers for bodied macros that remain unresolved (with no clear communication on whether or when they will be addressed). In practice, we’re being asked to reduce what our app can do for customers or continue with an increased revenue share to Atlassian at exactly the moment a native alternative arrives. That timing is hard to absorb, and it damages trust in the ecosystem investment case.

We’re committed to continuing this conversation and appreciate that Atlassian has opened the door to feedback. We hope it leads to concrete clarity, particularly for vendors navigating Connect-to-Forge migration alongside announcements like this.

The problem with mimetic rivalry is your products eventually look similar to your competitors and the market compares them on a 1:1 basis. That’s a losing game against more nimble foes with much less tech debt.

Atlassian’s core competitive advantage is customisability to suit any enterprise workflow, and the largest third-party app marketplace to deliver on that infinite longtail of customer needs.

The core products (Jira + Confluence) should be lightweight thin clients like an operating system for work. While the Forge platform and marketplace apps should be the infinite customisable extensibility that users can install into that OS.

A strategy like this would lean into Atlassian’s core competitive advantage, dramatically reduce operating costs, focus resources on a true platform-scale model with asymmetric returns, eliminate UI/UX bloat to unlock new customer segments, keep marketplace partners motivated to deliver innovation at little cost to Atlassian, and build far greater resilience in the generative software era.

/2c

I don’t understand why this is being shared as a “Request for Comments.” This is an early release announcement, not something open for meaningful feedback. I’m not sure what kind of comments you’re expecting on this change.

This feels like a middle finger to all the partners who helped build the ecosystem. That’s all I can say.

As a customer, I love that this is becoming a native macro, but the timing and the advance announcements towards marketplace partners are, quite frankly, insulting.

I disagree with @nathanwaters that Confluence should be lightweight thin clients, and apps should extend the functionality for the simple reason that the Atlassian platform is marketed as an Enterprise product. There are expectations in that statement, and being forced to buy additional functionality, which often does not match the design of the standard platform, I might add, has turned many customers to other solutions. This is not the path forward, and basic macros for organizing content should have been added a decade ago.

Confluence is no longer a Wiki. It is a content engine that drives not just Company Hub functions, but also areas like the portal in Customer Service Management. It needs to evolve, and many marketplace apps will see themselves replaced, just like we see here with Tabs. This is inevitable as the Atlassian platform evolves to the new one we have seen being rapidly developed (for better or worse).

That being said, the transition has to be handled better than this.

Getting 4-6 weeks’ notice during the holiday season when many are off on vacation is not ok. That is an insult to the marketplace partners that have spent time and effort to fill a gap in the features Confluence has offered.

You can not make business decisions on such short notice, and the impact is severe for some marketplace apps in this specific area.

While this is a small addition to Confluence, it affects quite a lot of marketplace app partners. This should always be considered, and when you disrupt business like this, at least contact the marketplace partners directly at least 3 months before publication to give them time to try to absorb the change.

Atlassian is running at the moment, but please remember that the key phrase is PARTNER, and partners treat each other with respect. I think this was missed here, and while I am sure there are no ill intentions involved, the road to hell is paved with good intentions…

Please slow down and make changes respectfully, as people’s income and businesses are affected by the rapid changes you make.

We are partners after all, and while Tabs may be amazing new features, surely they can wait until after Team 26 in October, giving partners time to adjust and plan for it?

Not necessarily. These marketplace vendors exist: Atlassian and Atlassian Labs.

This new tabs feature (and all first-party macros) could simply be free Forge apps listed by Atlassian on the marketplace.

From there it’s an onboarding flow to match customer needs to marketplace solutions.

In some ways that would put first-party macros on an equal playing field as third-party macros: both use the same available Forge modules and both have to earn the user’s install. Though of course the listing would compete with partners unless you de-ranked in search results.

You are right, I forget about those and I see your point.

From a customer perspective I see that extending capabilities like adding Figma or GitHub capabilities makes sense, but macros in Confluence would be a hard sell.

Still, I appreciate you correcting me and remind me of the distinction of 1st and 3rd party vendors. I would love to discuss the modularity of what you are suggesting, but this is not the thread for it I think :slight_smile:

I do like your suggestion to release this specific feature in that way for a period of time. That would allow for existing apps to compete and perhaps evolve before the native tabs are merged into the solution.

That would make perfect sense for when new features like this are added.

I like it.

It is not an RFC but an announcement. Atlassian is not asking for input, it is simply telling us upfront that this is happening.

You’re right, that’s my bad, I’m just used to RFCs being used in this way.

The rest of the statements still stands.

Hey @LauraMehrkens + Confluence Team,

First off, thank you for bringing this to the developer community ahead of release and spending time with effected partners. It is appreciated.

Adaptavist (and its business unit, Kolekti) has been supporting mutual customers in the content formatting space since before the marketplace was launched, with Mosaic Content Formatting being the first app on the marketplace. Over the years, our product and professional services have helped drive Confluence adoption, content customisation and made it more approachable for business teams.

With Atlassian’s move to expand further into the content formatting experience by introducing Cards, Carousel, Company Hub, and now Tabs, we’ve seen the value we can offer erode. While we can understand the need to improve the core Confluence experience for users, this hasn’t been done in conjunction with the marketplace. We have also steadily seen a reduction in extensibility as we’ve supported Atlassian and customers through the transition from P2/DC>Connect>Forge.

Put bluntly, Confluence has become more of a walled garden where partners aren’t welcome to innovate over the years. Confluence native macros aren’t built on Forge (so don’t easily nest or work with other 3rd party macros), no new features ship with extensibility (Whiteboards, Databases, Remix and Slides) and the formatting experiences we can offer have become more restricted with Forge egress limits.

We would like to assist Atlassian in hitting their goals, but in order to do so, we need to have open conversations about the future of what content creation will look like in light of agentic workflows and Rovo-powered user journeys. We need to collaborate instead of having Atlassian ship and partners react. The current approach sends a concerning signal: vendors can invest for years in Atlassian’s platform, build customer adoption, and still face Atlassian entering the same space directly instead of supporting or accelerating that existing innovation.

You’ve got a cohort of partners here who are passionate about this space and have built businesses to serve your customers. How can we take this conversation forward into a very exciting time for content creation? Or put another way, how can vendors invest with confidence instead of hedging every roadmap against the next announcement?

I usually find @remie a little too strident in his criticisms of Atlassian, but this time, he echoes my thoughts pretty accurately. Sometimes it’s unclear whether Atlassian is a partner, a supplier of services, or a competitor; or maybe all three at once.