That is where Workzone for Bitbucket Cloud becomes the stronger option. Workzone is priced at $0.50 per user/month, and when paired with Bitbucket Standard at $3.65 per user/month, it gives teams a way to add structured reviewer rules, merge controls, and compliance-focused approvals without stepping up to Premium pricing. Instead of upgrading to a more expensive Bitbucket tier just to fill pull request governance gaps, teams can stay on Standard and add the controls they actually need.

Feature	Workzone + Bitbucket Standard Plan	Bitbucket Premium + .codeowners
Pricing	Workzone = $0.50 / user / monthTotal Approx. $4.15 / user / month	Approx. $7.25 / user / month
Cost Advantage	≈ $3.10 less per user/month	Higher total monthly cost
Configuration UX	Web UI, REST API, and JSON; unified setup for reviewers, merge checks, auto-merge, and digital signatures	Repository-based .CODEOWNERS config file with DSL/syntax
Configuration Scope	Workspace, Project, and Repository levels	Repository level only
Reviewer Assignment	Path-based, group-based, and conditional assignment	Native path-based assignment via .codeowners, no reviewer groups
Approval Quotas	Explicit reviewer, group, and file/path approval quotas	No approval quotas in .codeowners itself
Mandatory Reviewers	Enforces mandatory reviewers or groups and can auto-re-add them if removed	Not available
File/Path Mandatory Reviewers	Enforces mandatory users/groups for specific files or paths, with quotas	Not available
Conditional Reviewer Assignment	Can add reviewers/groups only after successful build passes	Not available
Merge Enforcement	Included; granular merge rules and quotas without needing Bitbucket Premium	Enforced merge checks are tied to Premium
Automation	Auto-merge when checks pass; can trigger on approvals and successful builds	Limited native automation; auto-merge mainly around build-based conditions
Config Security / Governance	Settings managed by designated admins via UI/API; harder to bypass	.codeowners file lives in the repo and can be edited by users with push access
Compliance / Digital Signatures	Supports enforced digital signature approvals for auditable approval workflows	No native PR approval digital signatures; Premium security controls focus on access controls like 2FA / IP allowlisting

That means Workzone + Bitbucket Standard comes to about $4.15/user/month — roughly $3.10 less per user/month, or about 42.8% cheaper than Bitbucket Premium. For teams that need stronger pull request governance and compliance evidence without stepping up to Premium, that’s a much stronger value story.

Cost Comparison

The comparison above makes the tradeoff clear. If all you want is basic native path-based reviewer assignment, .codeowners may cover that narrow use case. But for teams that need mandatory reviewers, approval quotas, stronger merge enforcement, admin-managed configuration, and auditable digital signatures, Workzone delivers a much more complete pull request governance layer than native code owners alone.

For teams focused on cost control, process enforcement, and compliance readiness, that changes the conversation entirely. The question is not whether Premium has extra features — it is whether those extra features are worth paying for when your actual goal is better pull request governance. In many cases, Workzone + Bitbucket Standard is simply the more targeted and more cost-effective choice.

The post Comparing the Cost of Workzone + Bitbucket Standard vs Bitbucket Premium + .codeowners first appeared on Atlassian Apps for Efficient Teams.

Development teams should do the same.

Over time, even strong DevOps practices can collect “process clutter”:

• approval steps nobody questions anymore
• manual handoffs that slow down progress
• inconsistent pull request rules across repositories
• limited visibility across teams
• compliance checks that happen too late (or only when someone remembers)

The result? More friction, slower releases, and more effort spent managing process than shipping value.

The good news is that a DevOps reset doesn’t need to mean a complete overhaul. Often, a few focused changes can make a big difference.

Here are some fresh ideas for Bitbucket teams looking to clean up old habits and improve how they work.

What “process clutter” looks like in Bitbucket teams

Most teams don’t create inefficient processes on purpose. They evolve them over time, usually for good reasons:

• a rule was added after an incident
• an extra approval was introduced for a sensitive repo
• a manual checklist became the “safe” fallback
• a team adopted different conventions than everyone else

Individually, these changes make sense. But together, they can create a DevOps environment that feels heavy and inconsistent.

Some common signs:

• PR cycle times are longer than they should be
• teams can’t easily see what’s blocked and why
• release coordination depends on a few people
• audit/compliance evidence is hard to collect
• engineers work around process instead of trusting it

A spring clean is about removing that friction, without losing control.

1) Audit your pull request flow before adding more rules

Before introducing new tooling or governance, start with a simple question:

Where are PRs actually getting stuck?

Look for:

• repeated review bottlenecks
• inconsistent approval expectations
• PRs waiting on the same people
• merge delays caused by unclear ownership
• “invisible” blockers across multiple repos

This helps you avoid a common mistake: adding more process to fix a visibility problem.

Fresh idea:

Run a short “PR flow review” with engineering leads and identify:

• what should be standardized
• what should be automated
• what should be removed entirely

If you want to use this checklist for yourself, you can download it here! We recommend copying it over to Confluence and be sure to involve the right people from your team,

2) Standardize what matters, not everything

One of the biggest sources of DevOps friction is inconsistency.

If every repository has different expectations for approvals, reviewers, or merge readiness, teams waste time relearning the process each time they move across projects.

That doesn’t mean every repo should be identical. But your core controls should be consistent.

Examples of high-value standardization:

• required reviewers for sensitive code areas
• consistent approval policies for key branches
• merge guardrails for critical projects
• defined handoff points for release-related PRs

Fresh idea:

Create a “minimum viable governance” model:

• a baseline for all repos
• stronger controls only where risk justifies it

This keeps teams moving while still supporting compliance and quality goals.

3) Shift-left compliance checks earlier in the workflow

As AI-assisted coding becomes more common, compliance and governance are becoming more important, not less.

The challenge is making compliance part of the development flow instead of a last-minute release headache.

If checks only happen at release time, teams end up with:

• rushed exceptions
• missing evidence
• manual reconciliation
• delayed deployments

Fresh idea:

Treat compliance as a continuous workflow discipline inside the PR process:

• enforce the right checks at the right stage
• capture evidence as work happens
• reduce manual follow-up later

This is where teams often get the biggest improvement: better governance and less rework.

4) Improve cross-repo visibility for merge and release coordination

As teams scale, it becomes harder to understand the state of work across repositories, especially when release readiness depends on multiple PRs landing in the right order.

Without visibility, teams rely on:

• Slack messages
• spreadsheets
• status meetings
• “Can someone check this PR?” pings

That creates coordination overhead and slows delivery.

Fresh idea:

Make PR status and merge sequencing visible across teams so leads can quickly spot:

• blocked work
• dependencies
• merge readiness risks
• bottlenecks before release windows

This is especially useful for platform teams, shared services, and enterprise environments where multiple teams contribute to the same release outcome.

5) Replace tribal knowledge with repeatable workflows

If your most critical DevOps processes only work because a few senior people know the “real” steps, that’s a risk.

Spring cleaning is a good time to turn:

• undocumented conventions
• informal approval paths
• manual release rituals

into repeatable workflows that the broader team can follow.

Fresh idea:

Document the workflow and support it with tooling, so the process is:

• clear
• visible
• easier to enforce
• less dependent on individual memory

This improves onboarding, resilience, and consistency, especially as teams grow.

6) Make one meaningful improvement this quarter (not ten)

A full DevOps transformation can feel overwhelming. Most teams get better results by focusing on one or two high-impact changes first.

For example:

• reducing PR bottlenecks in critical repos
• improving merge visibility across teams
• introducing stronger compliance guardrails for sensitive code paths
• improving release readiness coordination

Fresh idea:

Pick one measurable goal for your “spring refresh,” such as:

• faster PR turnaround
• fewer release delays
• less manual compliance effort
• better cross-team visibility

Then build from there.

Where Workzone and Organizr can help Bitbucket teams

If your spring clean reveals that the biggest issues are around PR governance, compliance, and visibility, this is where purpose-built Bitbucket apps can make a difference.

Workzone (for PR automation and compliance enforcement)

Workzone helps teams strengthen pull request workflows by supporting more structured, enforceable processes, particularly useful when you need stronger governance without relying on manual policing.

This can be valuable for teams looking to:

• reduce manual review/admin overhead
• enforce approval and workflow expectations more consistently
• support audit and compliance efforts in day-to-day development workflows

Organizr (for global PR visibility and merge orchestration)

Organizr helps teams improve visibility across pull requests and coordinate merge activity more effectively, especially in environments with multiple repos, dependencies, or shared release timelines.

This can be valuable for teams that need:

• better cross-repo visibility
• clearer understanding of what’s blocked
• improved merge coordination for release readiness

Turning a spring clean into a bigger DevOps improvement (without forcing change)

For some teams, a few process updates are enough.

For others, a spring clean uncovers a broader opportunity:

• PR flow is inconsistent
• compliance is too manual
• release coordination is fragile
• teams lack shared visibility

That’s where a service bundle approach can make sense.

Instead of solving one problem at a time, you can address the bigger workflow outcome, for example:

• PR Flow Optimisation
• Release Readiness & Traceability
• Compliance / Governance-focused DevOps improvements

This approach helps teams improve delivery speed, governance, and operational clarity together, rather than treating them as separate projects.

Final thought: Don’t just clean up, make space for better ways of working

Spring cleaning isn’t just about removing what’s old. It’s about making room for what works better.

For Bitbucket teams, that could mean:

• simpler PR workflows
• stronger (but lighter) governance
• better visibility across teams
• less manual coordination
• more confidence heading into releases

If your team is reviewing old processes this season, it’s a great time to refresh your DevOps workflow, and build a cleaner foundation for the next phase of growth.

Thinking bigger than a quick cleanup?
A spring review is the perfect time to assess a broader DevOps service bundle focused on PR flow optimisation, compliance, and release readiness in Bitbucket.

Interested to learn more about Workzone and Organizr mentioned above?

The post Spring Clean Your DevOps Process: Fresh Ideas for Bitbucket Teams first appeared on Atlassian Apps for Efficient Teams.

“Here’s a Bitbucket app that enforces pull request rules.”
“Here’s another that helps you find the right pull requests.”

But that’s not really how Atlassian Solution Partners sell.

Partners don’t go to customers with “a plugin”.
They go in with service offerings:

• “We’ll tighten up your release process.”
• “We’ll reduce your pull request bottlenecks.”
• “We’ll help you get your DevOps governance under control.”

That’s why we’ve started to reframe our Bitbucket-focused product line as service accelerators and package them into Solution Partner-ready service bundles.

This post is about why we’re doing that, and what’s in it for you as a Solution Partner.

The gap we kept seeing in Bitbucket projects

In conversations with partners and customers, the same pattern kept popping up:

• Customers want outcomes like safer releases, faster reviews, and better auditability,
  not “yet another app to configure”.
• Partners want repeatable, productised services they can sell again and again,
  not a brand-new workshop and bitbucket-pipelines.yml for every engagement.
• Everyone is under pressure to show value quickly, especially in Data Center and hybrid environments where tooling sprawl is already real.

Our apps already solve very specific problems in Bitbucket:

• Enforcing pull request workflows and merge rules
• Surfacing the right metadata across repositories
• Nudging people to review and approve work on time

But when we only presented them as individual apps, there was still a translation step:

“How do I turn these into a concrete service I can sell, price, and deliver as a partner?”

So we decided to meet partners where they already are: selling outcomes, not plugins.

From “apps” to “accelerators”: how we now frame things

Instead of leading with products, we now think in terms of named service bundles a partner could actually put on a slide.

Examples:

• Release Readiness & Traceability
  Help teams know exactly what’s going into a release, who approved it, and where it’s running.
• Pull Request Flow Optimisation
  Reduce cycle time and review fatigue by standardising how PRs move from “opened” to “merged”.
• PR Governance & Compliance
  Enforce review policies, approvals, and checks in Bitbucket — with the audit trail to prove it.

Each bundle has three layers:

1. Outcome & story
   • What problem it solves (“We keep getting surprised at release time”)
   • Who cares (Dev, DevOps, Platform, Compliance, leadership)
   • What “good” looks like (shorter lead time, fewer rollbacks, cleaner audit evidence)
2. Partner services
   • Current-state assessment of Bitbucket and pull request practices
   • Design of target workflows and governance policies
   • Implementation in Bitbucket (and often Jira/Confluence around it)
   • Training, coaching, and periodic health checks
3. Our apps as accelerators
   • Opinionated app configurations and templates
   • Pre-built rules, guardrails, and dashboards that back up the service
   • Documentation and examples tuned for delivery, not just admin toggles

So instead of saying:

“Here’s App X. It has features A, B, and C.”

…you can say:

“We offer a Release Readiness & Traceability package.
In 4–6 weeks, we’ll get you from ‘we hope this release is fine’ to
‘we know exactly what’s going out, and we can prove it’ — powered by Izymes’ Bitbucket accelerators.”

That’s easier to sell. And it’s much closer to how partners already position their services.

Why this approach makes sense for us as a vendor

Being candid: we’re not doing this just because it sounds nice on a slide. It also makes sense for us.

1. A value story that isn’t “yet another plugin”

When we talk to customers and partners in terms of:

• release safety,
• PR throughput,
• and governance,

it’s immediately clear why our apps matter.

It moves the conversation away from line-item features and towards business outcomes that budget owners actually care about.

2. Deeper, more deliberate adoption

When our apps are part of a structured engagement led by a Solution Partner:

• They get designed into real workflows, not just installed and left on defaults.
• There’s a clear rollout plan, training, and follow-up.
• People actually use the features we built.

That leads to more meaningful feedback, better renewals, and a product road map shaped by real use, not just wish lists.

3. Alignment with how partners make money

Partners make their money on:

• consulting and implementation,
• recurring managed services,
• and long-term client relationships.

If our apps are positioned as service accelerators, we’re not competing with that model — we’re supporting it.

We want you to be able to say:

“We have a packaged offer we can run over and over, and Izymes gives us the tooling and patterns to deliver it faster and more reliably.”

If partners win more work with our stack, and keep those customers happy, everyone wins.

What Solution Partners actually get out of this

Let’s look at it from your side.

1. Ready-to-productise service offers

You don’t have to start from a blank page.

We provide:

• named bundles (like Release Readiness & Traceability),
• a clear problem statement and outcome,
• suggested engagement structure (assessment → design → implementation → training → check-ups),
• and the recommended app combination and config patterns.

That’s the raw material for a repeatable, productised service you can price, quote, and reuse.

2. Faster time-to-value (with fewer “science projects”)

Because the patterns are already thought through:

• You spend less time rediscovering the same best practices.
• Delivery teams can lean on templates and reference configurations.
• Customers see tangible improvements sooner — which helps you make the case for phase two.

3. Higher margins with less delivery risk

Repeatability is where margins improve.

• You refine the same engagement pattern over time.
• You know which gotchas to avoid in Bitbucket and in team workflows.
• You can safely delegate more to your delivery team, because the playbook is already proven.

The apps simply act as the backbone that makes your process stick.

4. A differentiated story in the Atlassian ecosystem

Not every partner is walking in with an opinionated Bitbucket-centric DevOps offering. Or, for that matter, customers do not knock on your door with an exact Bitbucket-centric requirement spec.

Arriving with a named accelerator, clear outcomes, and tooling to back it up sends a different message:

“We’re not just here to turn things on.
We’re here with a tested way of working that we’ll adapt to your context.”

That’s powerful in competitive situations where customers are comparing several partners who all “do Atlassian”.

How we’re supporting partners behind the scenes

To make sure this isn’t just a PDF that gathers dust, we’re investing in enablement for partners:

• A Service Offering Deck you can adapt and rebrand for your own pitches
• Suggested implementation patterns, including typical phases and milestones
• Example configurations and rulesets you can use as a starting point
• Direct collaboration on real opportunities where our accelerators are a fit

We want it to feel less like “installing someone else’s app” and more like:

“We’ve teamed up with a vendor who understands how Bitbucket is actually used in the wild, and who has built tooling that supports the way we deliver services.”

If you’re a Solution Partner, here’s what you can do next

If any of this resonates and you’d like to see how it could fit into your Bitbucket / DevOps portfolio, we’re happy to share more.

You can:

• Download the Service Offering Deck
  Get the current version of our partner-facing deck with example bundles, positioning, and talking points you can adapt.
• Get in touch with us
  Have a client or use case in mind already? Reach out and tell us a bit about your situation — we’ll happily suggest where our accelerators fit (and where they don’t).
• Book a call to explore a joint offering
  If you’d like to go deeper, we can walk you through the bundles, discuss how they map to your existing services, and look at co-selling options for specific accounts.

Drop us a line, grab the deck, or book some time — and let’s see if we can turn “a few Bitbucket apps” into a set of services that your customers will actually recognise, buy, and keep coming back for.

The post Turning Bitbucket Apps into Service Bundles: Our Approach for Atlassian Solution Partners first appeared on Atlassian Apps for Efficient Teams.

Instead, the real story of the year was a mindset change:

We stopped leading with individual app features, and started building partner-ready service bundles that sell outcomes.

That shift shaped almost everything we did this year: how we talked to Solution Partners, how we showed up at Team ’25 (Anaheim and Barcelona), how we ran our Compliance Alliance sessions, and how we’re thinking about the Atlassian platform as it accelerates into the AI era.

The big theme: from “apps” to service bundles

For years, Marketplace vendors (including us) have marketed like this:

• “Here’s an app that enforces pull request rules.”
• “Here’s another app that helps you find the right pull requests.”

But that’s not how Solution Partners sell.

Partners sell repeatable services:

• “We’ll tighten up your release process.”
• “We’ll reduce PR bottlenecks.”
• “We’ll help you pass audits with less chaos.”

So this year, we leaned hard into a new framing: Izymes apps as accelerators inside partner-led service offerings.

If you’ve read our post Turning Bitbucket Apps into Service Bundles: Our Approach for Atlassian Solution Partners, you’ll recognise the structure we’ve been refining:

• Outcome & story (what “good” looks like)
• Partner services (assessment → design → implementation → enablement)
• Our apps as accelerators (rulesets, templates, dashboards, guardrails)

It’s a simple change in packaging, but it removes a massive translation step for partners:

“How do I turn these tools into something I can pitch, price, and deliver?”

What we shipped: Advanced Status Labels (and why it matters)

We also launched Advanced Status Labels, expanding our footprint beyond Bitbucket into Confluence.

On the surface, that’s “just a new app.”

In the context of 2025’s bigger theme, it’s also part of the same story: helping teams make work visible, structured, and repeatable, whether that’s governance in Bitbucket or clarity on Confluence pages.

Team ’25 Anaheim: the “AI + system of work” year really arrived

Team ’25 in Anaheim felt like the moment Atlassian stopped talking about AI as an add-on… and started treating it as the foundation.

A few takeaways that stuck with us:

1) Rovo moved front-and-centre

Atlassian positioned Rovo as a core teammate across Jira/Confluence/JSM, not a side feature, and announced “Rovo for all” at Team ’25.

2) Collections became the new packaging language

Instead of a dozen disconnected products, Atlassian’s story leaned into bundled “Collections” (Teamwork, Strategy, etc.) as the way customers buy and adopt a system of work.

3) Partners are being pulled into a faster cadence

The signal was clear: Cloud innovation + AI capabilities are moving quickly, and partners who can package repeatable outcomes (not just implementations) are going to win more often.

For us, Anaheim reinforced that our service bundle direction wasn’t just “nice positioning”, it was aligned with where Atlassian is taking the ecosystem.

Team ’25 Europe Barcelona: Rovo “everywhere”, and the platform keeps bundling

Barcelona wasn’t a repeat, it was an escalation.

Atlassian doubled down on AI being embedded “across every surface,” and introduced new Collections that matter a lot for how customers will package buying decisions going forward, including the Software Collection and the Service Collection.

The headline feeling from Barcelona was:

• Rovo is becoming the intelligence layer
• Collections are becoming the commercial layer
• Partners need to become the outcomes layer

That maps perfectly to the bundle approach we’ve been building: partners lead the engagement, and our accelerators make it faster, safer, and more repeatable.

The Compliance Alliance workshops: what we kept hearing (and why we ran them twice)

One of the highlights of the year for us was running the Compliance Alliance workshops at both Team ’25 events, bringing together folks across the ecosystem (especially vendors) to talk seriously about compliance in the Atlassian space.

The consistent theme wasn’t “more features.”

It was:

• auditability without friction
• governance without grinding delivery to a halt
• traceability that doesn’t rely on tribal knowledge

Which… is basically the entire reason bundles like PR Governance & Compliance and Release Readiness & Traceability exist.

These sessions didn’t just validate the direction, they sharpened it.

The biggest market shift: Data Center end-of-life (with a critical Bitbucket exception)

This one shaped a lot of partner conversations in the second half of the year.

Atlassian has now set a formal end-of-life timeline for impacted Data Center products, including a wind-down starting March 30, 2026, and an end-of-life date of March 28, 2029 (when impacted Data Center products and their Marketplace apps become read-only).

But importantly for us (and for many of our customers): this does not apply to Bitbucket Data Center. Atlassian explicitly states that Bitbucket Data Center will not end of life, and that existing Bitbucket Data Centre customers will get access to a Bitbucket Hybrid License (DC + Cloud).

Because so much of what we do is Bitbucket-centric, that exception matters. It means:

• Bitbucket remains a serious long-term option for customers with sensitive source code requirements
• “Hybrid” becomes a real operating model, not a temporary bridge
• Partners will need offers that work across mixed environments, and can be delivered repeatably

Which (again) pushes the ecosystem toward packaged services, not one-off bespoke projects.

What this sets up for 2026

If 2025 was the year we changed the way we talk, 2026 is the year we keep turning that into partner momentum:

• more bundle enablement (templates, reference configs, delivery patterns)
• deeper partner collaboration on real opportunities
• clearer “sell the outcome” stories tied to Bitbucket governance, release readiness, and PR flow
• practical alignment with where Atlassian is heading: AI embedded everywhere, buying packaged as Collections, delivery won through repeatable services

If you’re a Solution Partner…

If you’re building (or refining) your Bitbucket / DevOps offerings and you want them to be easier to sell and safer to deliver:

• Download the Service Offering Deck
  Get the current version of our partner-facing deck with example bundles, positioning, and talking points you can adapt.
• Get in touch with us
  Have a client or use case in mind already? Reach out and tell us a bit about your situation, we’ll happily suggest where our accelerators fit (and where they don’t).
• Book a call to explore a joint offering
  If you’d like to go deeper, we can walk you through the bundles, discuss how they map to your existing services, and look at co-selling options for specific accounts.

Because the goal isn’t “install some apps.”

It’s to help you walk into accounts with something customers recognise, buy, and come back for:
a named, outcome-driven service, powered by accelerators that make it stick.

The post Izymes 2025 Wrap: The year we stopped selling “apps” and started packaging solutions first appeared on Atlassian Apps for Efficient Teams.

To keep the app healthy long-term (and to keep improving it), we’re introducing a paid subscription model.

Transition date: 28 January 2026
Good news: the app will remain free for teams up to 10 users.

Why we’re adding a subscription

Running a Confluence Cloud app isn’t “set and forget.” As the app has grown, so have the ongoing costs to keep it reliable, secure, and supported.

Here’s what your subscription helps us cover:

• Ongoing maintenance & support
  Keeping the app compatible with Atlassian platform changes, fixing bugs quickly, answering support requests, and maintaining documentation.
• Atlassian hosting & platform costs
  Atlassian Cloud apps incur real infrastructure and platform-related costs (including hosting and operational overhead). Subscription revenue helps offset those recurring costs so the app can stay sustainable.
• Continuous improvement
  Subscriptions fund ongoing development—performance improvements, UX polish, new label options, admin controls, and the features you’ve been asking for.

In short: we’d rather charge a small, fair amount and keep the app actively maintained than keep it free and be forced to slow down support and development.

What’s changing on 28 January 2026?

From 28 January 2026, Advanced Status Labels will require a paid subscription for teams above the free tier.

If you already have the app installed, you’ll see an in-app banner with the transition date and a link back to this page. Atlassian will guide admins through the subscription step as part of the normal Marketplace experience.

What’s not changing:

• The app stays available on the Atlassian Marketplace.
• Teams up to 10 users remain free.
• We’ll continue supporting the product and shipping improvements.

Pricing

Pricing is per user (USD/month), based on your team size:

A couple of quick examples (monthly):

• 50 users → 50 × $0.30 = $15/month
• 200 users → 200 × $0.25 = $50/month
• 800 users → 800 × $0.20 = $160/month
• 3,000 users → 3,000 × $0.10 = $300/month
• 10,000 users → 10,000 × $0.05 = $500/month

Note: Atlassian may add applicable taxes based on your region.

FAQ

Will the free tier still exist?

Yes — up to 10 users stays free.

Do we need to do anything right now?

Not necessarily. If you’re above 10 users, just be aware of the 28 January 2026 transition date. We’ll provide clear guidance in-app and on the Marketplace flow.

What happens if we don’t upgrade to the paid subscription?

Once the paid subscription has been introduced on the 28th January 2026, limitations will be implemented for spaces that have not yet transitioned to the paid subscription. These limitations include;

• Limit of 5 categories
• Limit of 5 values per category
• Limit of 5 search results

Important: When the paid subscription has been introduced, you will not lose any of your current data. All Status Labels you have created will stay visible. If you have already exceeded the limitations when the paid subscription is introduced, the limitations will immediately take effect until the upgrade occurs.

Are there limitations for new licenses as well?

No, there will be no limitations with for new licenses apart from the typical 30 day evaluation period.

What if we have questions about pricing or procurement?

Reach out here and we’ll help you work through it.

Thanks for supporting Advanced Status Labels

We built Advanced Status Labels to make Confluence pages clearer, faster to scan, and easier to keep up to date. Moving to a subscription helps ensure we can keep investing in the product and supporting the teams who rely on it.

If you have questions, want to share feedback, or want to understand what’s coming next, please feel free to get in touch.

The post Advanced Status Labels for Confluence is moving to a paid subscription (effective 28 January 2026) first appeared on Atlassian Apps for Efficient Teams.

Atlassian has officially announced that Data Center products will reach End of Life (EOL) on March 28, 2029. This marks a major shift in Atlassian’s strategy, with the company doubling down on its cloud-first future. If you’re currently running Jira, Confluence, or other Atlassian products in Data Center (not so much Bitbucket, we will touch on this later), this update will have a big impact on your roadmap.

In this post, we’ll break down what’s changing, the key milestones in the EOL timeline, and how you can prepare.

Why Atlassian Is Making This Change

Atlassian highlighted that 99% of its customers are already in cloud or on the path to cloud, including 75% of enterprise and regulated industries. The move is framed as an opportunity to unlock:

• Faster time to value
• Reduced costs
• AI-enabled teamwork that Atlassian is rapidly building into its cloud platform.

In short: Atlassian wants to focus its innovation and resources on cloud, not maintaining parallel Data Center offerings.

How this will affect Bitbucket Data Center Customers

If you’re a Bitbucket Data Center customer, the good news is that Bitbucket DC is not impacted by the broader Data Center End of Life timeline. Atlassian has confirmed that:

• Bitbucket DC is not affected by Data Center EOL – it will remain available beyond 2029.
• Dual licensing is offered – customers can run Bitbucket DC and Bitbucket Cloud in tandem under a single license arrangement.
• Bitbucket DC apps are not affected – Marketplace apps for Bitbucket DC will continue to be supported and sold.

Izymes Apps for Bitbucket Data Center (Not Affected by EOL)

• Workzone for Bitbucket – available on both Data Center and Cloud, including a built-in migration tool to simplify the move between hosting models.
• Organizr for Bitbucket – fully supported on Bitbucket DC.
• Reminders for Bitbucket – fully supported on Bitbucket DC.

At Izymes, we are also working closely with Atlassian to enable dual licensing for Workzone across Bitbucket DC and Cloud, ensuring that both solution partners and customers can take advantage of this flexibility without disruption.

Learn more about dual licensing here…

What This Means for Customers and Partners as a Whole

If you’re an Atlassian customer on Data Center today, here’s what this means:

1. You can keep running Data Center until 2029 – but your ability to purchase new licenses, expand, or add Marketplace apps will gradually shut off starting in 2026.
2. Marketplace ecosystem changes – new apps for DC won’t be accepted after December 2025, and app sales will be phased out entirely by 2028.
3. Migration is unavoidable – cloud will become the only long-term path for most customers. I say most, as it seems Atlassian will continue allowing Bitbucket Data Center to be dual-licensed with Cloud. Great news for our enterprise customers using Workzone: Pull Request Workflow and Global Pull Request Organizr.

For Marketplace partners and app vendors, this means aligning your strategy with cloud adoption and helping customers through the migration journey.

How to Prepare Now

• Audit your current Data Center usage: Identify which products, apps, and customizations you’re running.
• Start planning migrations: Even if you don’t move immediately, knowing your roadmap early avoids panic in 2028.
• Engage your vendors: Check if your critical Marketplace apps are available in cloud. If not, push for alternatives.
• Lean on Atlassian Partners: Atlassian Partner Managers and solution providers will be key allies during this transition.

This is one of the biggest changes Atlassian has made since ending support for Server. While Data Center customers have a few more years of runway, the writing is on the wall: the future is cloud.

If you’re running on Data Center today, the best time to start planning your migration was yesterday. The second-best time is now.

For those customers of ours using our tools Workzone: Pull Request Workflow and Global Pull Request Organizr in Data Center, it looks as though you will be less affected than the other core products.

The post Atlassian Data Center End of Life– What You Need to Know first appeared on Atlassian Apps for Efficient Teams.

Jira Hooks for Bitbucket + Workzone: PullRequest Workflow = Peace of mind with confidence and velocity built in

Introduction

An efficient and secure software development process is more critical than ever. Tools like Jira and Bitbucket from the Atlassian portfolio form the technical foundation for many development teams. However, only with extensions such as Jira Hooks for Bitbucket and Workzone: PullRequest Workflow can the process truly become robust, compliant, and process-secure.

In this blog article, we show how these two add-ons work hand in hand to validate commits, pull requests, and merges, integrate Jira processes, and eliminate typical sources of error in the development lifecycle.

1. Why Secure the Development Process?

The larger the team and the more complex the codebase, the greater the risk of inconsistent processes: incomplete pull requests, missing Jira references, unreviewed code in the main branch, or incorrectly chosen reviewers who cannot assess the context of the changes. Without automated checks, these issues are often overlooked—with potentially critical consequences.

Proper technical enforcement enables teams to:

• Enforce quality assurance rules
• Automate compliance requirements
• Reduce errors and manual workload

In audits, it’s crucial that processes and procedures are not only described in well-designed flowcharts or detailed documentation but also technically enforced. Auditors want to see that processes are lived and technically secured.

Example: If a company claims that no code is merged into the main branch without QA review, it’s not enough to state this in a handbook. With Jira Hooks and Workzone, you can show: “This merge was blocked because no QA reviewer was assigned and the Jira issue was not in ‘Ready for Merge’ status.”

This kind of lived, technical process enforcement not only increases transparency but also simplifies audits significantly. It transforms theoretical claims into real compliance. The result is process and compliance assurance by design — integrated directly into the development workflow and traceable at any time.

It’s also important that this process security does not come at the cost of developer productivity or lead the team into bureaucratic dead ends. Such a system must not only secure processes but also engage the team, provide comfort, and introduce smart automation. Only when a workflow is both robust and developer-friendly will it be accepted and lived over the long term.

This is where Jira Hooks for Bitbucket and Workzone come into play.

A Typical Scenario from Developer Practice

A developer creates a feature branch, starts implementation, commits regularly, and pushes their code. No Jira ticket is mentioned in the commits because “they know what it’s about.” A pull request is created, but due to time pressure, a colleague is assigned as a reviewer who is unfamiliar with the topic. The review is waved through without proper scrutiny. The Jira ticket remains in “To Do” status — even though the code is already live. Traceability? None. QA approval? Overlooked. Merge conditions? Not defined — and thus not enforced.

In the end, the code lands in the mainline even though:

• No traceable technical review took place
• No Jira ticket was properly documented or referenced
• The process was never formally initiated
• No one can clearly say why this change was made or who approved it

The result is uncontrolled code management with high audit risk.

This example illustrates: Without clear technical control mechanisms, process security becomes a matter of luck, and compliance a mere wish.

2. Bitbucket as a Central Platform

Bitbucket serves many teams as the central Git platform for source code, branch management, and code reviews. But Bitbucket is more than just a remote Git repository: it is a comprehensive code management system that can map the entire lifecycle of code — from idea to release. With features like branch permissions, merge checks, pull request templates, build status integration, and comment functionality, Bitbucket provides the ideal foundation for embedding quality gates in the development process.

This structured control enables teams to not only document but also consistently enforce technical quality, security, and process compliance. Bitbucket provides a solid base, but its native capabilities alone are not sufficient to meet complex compliance, process, and documentation requirements.

However, Bitbucket allows for targeted expansion with powerful add-ons such as Jira Hooks for Bitbucket and Workzone. These tools turn Bitbucket into a system that not only manages code but also ensures process security, documentation, and review structure.

Bitbucket’s Three Control Points for Quality and Compliance

1. On the Developer’s Machine (Commit Time): At this stage, a first quality assurance process can be initiated using local Git hooks. This allows teams to be notified of potential issues early on. However, since this check can be easily bypassed, it serves more as a convenience and developer support than as a reliable process safeguard.
2. On Push to the Central Repository: Here, add-ons can establish the first enforceable quality gate. Invalid commits or unwanted conditions can be automatically detected and rejected. Typical scenarios such as the committer not being the assignee of the linked Jira issue or the Jira issue being in an invalid status can be addressed. This creates a clear checkpoint early in the process.
3. During Pull Request Creation or Merge: Bitbucket also offers the ability to enhance the entire process and its validation through powerful add-ons, thereby establishing process reliability. At the latest, when integrating code changes, compliance with quality standards, process requirements, and regulatory guidelines must be clearly ensured. If these requirements are not met, the integration must be consistently rejected.

It is precisely at these three points that the two add-ons, Jira Hooks for Bitbucket and Workzone: PullRequest Workflow, come into play and make targeted use of Bitbucket’s extension capabilities.

3. Jira Hooks for Bitbucket: Commit, Push, and Merge Validation with Jira

Jira Hooks for Bitbucket is a powerful add-on that extends Bitbucket with essential validation and checking mechanisms during commit, push, and merge operations. It steps in where traditional version control ends: by asking whether a change should be allowed in the first place.

The goal is to ensure that all commits and merges are bound to defined rules based on Jira data and naming conventions. These rules can reflect organizational, functional, or regulatory requirements.

Commit Checks:

When committing or pushing commits to a repository, Jira Hooks automatically verifies whether:

• A valid Jira Issue Key is present
• The linked issue belongs to a defined project or issue type
• The issue has an allowed status (e.g., “In Progress”)
• Naming convention of commit message and branch name
• The committer is the correct developer (e.g., listed as the assignee)

Jira Hooks recognizes issue keys in both the commit message and the branch name, enabling flexible workflows without compromising security. Additionally, issues can also be identified in pull requests, further enhancing traceability and control throughout the development process.

Merge Checks:

Merge conditions can also be defined, such as:

• Everything that is validated during a push can also be checked at merge time.
• Merges to the main branch are only allowed if the issue is in “Ready for Merge” status
• The issue key must meet project-specific criteria (e.g., sprint assignment, required fields)

JQL Checks:

With support for Jira Query Language (JQL), validations can be fine-tuned to match specific project requirements. If a JQL query does not match a valid Jira issue, the commit, push, or merge will be rejected accordingly. For example:

• Pushes are only permitted for stories, if the assignee matches the developer initiating the push.
• Only bugs in status “Ready for Dev” are accepted
• Custom fields must be filled
• Feature Freeze
• Commit Priming

Real-World Examples:

Here are some practical examples of how Jira Hooks for Bitbucket ensures process control in real development workflows:

• Unauthorized Merge Blocked: A developer attempts to merge a feature branch into main while the related Jira issue is still in status “To Do”. Jira Hooks blocks the merge and returns a message requiring the issue to be in “Ready for Merge” status.
• Missing Issue Key: A developer pushes commits to a branch named feature/new-login-flow. One commit lacks a Jira issue key, and the branch name doesn’t include one either. Jira Hooks blocks the push and returns an error, asking the developer to rename the branch (e.g. feature/PROJ-456-new-login-flow) and update the commit messages to reference the correct issue key. This ensures full traceability via both branch name and commits.
• Assignee Validation: A team has configured a rule where only the assigned Jira user is allowed to push changes to a given issue. If another developer (not the assignee) tries to push code related to that issue, the push is blocked until the assignment is updated or proper reassignment occurs.
• Feature Freeze Enforcement: A team has configured a rule to protect release branches during a feature freeze. During this period, no feature or development branches are allowed to be merged into a designated release branch (e.g. release/1.2). If a developer opens a pull request targeting the release branch, the merge is automatically blocked. This ensures stability and prevents unreviewed changes from entering production-critical code during release preparation.
• Commit Priming: A team has configured a rule that enforces alignment between commit messages and the Jira issue key defined in the branch name. For example, if a developer is working on a branch named feature/PROJ-123-new-ui, every commit pushed to that branch must include the issue key PROJ-123. If any commit is missing the correct key, the merge is blocked until the commit history is corrected. This rule ensures consistent linkage between code and Jira issues, supporting clear traceability and clean audit trails.

The result: A robust workflow where Jira is the single source of truth, and Bitbucket the gatekeeper that enforces those rules.

 Availability: Jira Hooks for Bitbucket is available for both Bitbucket Data Center and as a Forge App for Bitbucket Cloud. Due to limitations in the Cloud API, only merge checks are currently supported in the cloud premium variant.

4. Workzone: PullRequest Workflow

Workzone focuses entirely on securing and managing the pull request process. It bridges the gap between code and process by binding PR creation, review, and merge to enforceable rules.

The goal is not only to evaluate the code but also to ensure compliance with organizational standards, quality policies, and workflows — fully integrated into daily developer activity.

What Does Workzone Do?

Workzone allows teams to define pull request workflows for repositories or entire projects, including:

• How many reviewers are required, and which ones, based on the context of the change set (e.g., developers, team leads, QA)
• Digital signing of pull requests to meet regulatory requirements
• Automated merges once all defined criteria are met
• Active Directory (AD) – based reviewer groups with approval quotas, including enforced mandatory reviewers and reviewer groups (for compliance), each with required approval quotas.

Real-World Examples:

• A developer opens a pull request, and the system automatically assigns two technical reviewers. Only after both have approved does the next step become available.
• During review, compliance rules may require a reviewer approval to be digitally signed.
• Once all review and approval requirements are met (approvals, signature, and more), Workzone activates the pull request merge button or automatically merges the pull request.

 Availability: Workzone: PullRequest Workflow is available for Bitbucket Data Center and as a Connect App for Bitbucket Cloud.

5. Tool Integration: End-to-End Enforcement

The combination of Bitbucket, Jira Hooks and Workzone is especially powerful. These tools operate on different levels of the development lifecycle, from commit checks to pull request governance to merge validation, and form a tightly integrated, technically enforced quality and process assurance chain.

What Does End-to-End Mean?

End-to-end means that every phase of a change is automatically controlled, not just technically but also with regard to process logic, Jira status, reviewer configuration, and approvals.

Workflow Summary:

• Commit & Push: Jira Hooks checks whether referenced Jira issues exist and are valid. JQL can be used to validate issue context.
• Pull Request: Workzone assigns correct reviewers and verifies that all approvals are present. Digital signatures can be required. Jira Hooks validates issue status and fields.
• Merge: Both tools ensure that only authorized, complete, and traceable code is merged. Workzone can auto-merge once all conditions are met.

This seamless control makes processes auditable, reduces manual errors, and strengthens team accountability.

Additional Benefits:

• Every step is documented and audit-ready
• No reliance on manual checks or individual discipline
• Standardized process across teams, repos, and projects
• Fewer errors, misunderstandings, and exceptions
• Increased team velocity through context-sensitive automation based on smart rule-sets

The result: A process that is enforceable, supportive, and audit-compliant.

6. Conclusion: A Secure Development Process Without Friction

With Jira Hooks for Bitbucket and Workzone: PullRequest Workflow, development teams gain a consistently governed, traceable, and audit-ready foundation for their workflows — fully integrated into Bitbucket.

Instead of relying on manual checks or individual discipline, these extensions enable automated validation, rule-based approvals, and seamless Jira integration. They combine technical quality control with organizational compliance, all without compromising developer productivity.

Security, traceability, and efficiency are systematically embedded into every commit, push, pull request, and merge.

Compliance by design – available for both Bitbucket Data Center and Bitbucket Cloud. Install, integrate, and develop with confidence.

Audit trail, process, and compliance assurance by design. Whether on Bitbucket Data Center or Cloud.

7. Special offer! Get a Discount

Sounds too good to be true? Then go ahead and try out the two add-ons yourself — or even better, check out the promo codes. Boost your Bitbucket workflow – grab one of 10 exclusive promo codes for 20% off our top add-ons!

 20% Discount – Jira Hooks for Bitbucket

 20% Discount – Workzone: PullRequest Workflow

Install the add-ons today and secure your process by design:

• Jira Hooks for Bitbucket powered by DevOpsSystems GmbH
• Workzone: PullRequest Workflow powers by Izymes Pty Ltd

The post Securing the Software Development Process and Optimizing Bitbucket Workflows first appeared on Atlassian Apps for Efficient Teams.

Why Choose Workzone Cloud Over Bitbucket .codeowners?

While Bitbucket’s default .codeowners functionality provides basic support for managing code ownership and reviewers, Workzone elevates the process with powerful features designed for modern, enterprise-grade workflows. Here’s why Workzone is the superior choice:

1. Granular Control and Flexibility

With Workzone, you can configure rules at the global, project, and repository levels, ensuring consistency across your organization. The ability to enforce mandatory reviewers, manage approval quotas, and create complex merge conditions gives you unmatched flexibility, even for the most intricate workflows.

2. Enhanced Reviewer Management

Workzone allows you to assign reviewers using Active Directory groups, repository groups, or even specific file paths, ensuring the right people are reviewing the right code. It also re-adds mandatory reviewers if they’re accidentally removed, so critical reviews are never skipped.

3. Streamlined Merge Process

Our advanced merge checks and auto-merge capabilities streamline the development workflow. Whether you’re managing large teams or adhering to strict compliance standards, Workzone ensures that only code meeting all conditions gets merged—automatically.

4. Regulatory Compliance

Workzone’s digital signature approvals provide the necessary tools for industries with strict compliance requirements, such as healthcare, finance, and government. This ensures that every approval is traceable and auditable for peace of mind during audits.

5. Improved Security and Governance

Unlike .codeowners, which can be edited by anyone, Workzone limits configuration access to designated administrators at various levels. This minimizes the risk of accidental or unauthorized changes.

Real-Life Impact

Use Case: Scaling Development Teams

Imagine managing a large team of developers working on different parts of a monolithic repository. With .codeowners, maintaining consistent review and merge rules can quickly become chaotic, especially as teams grow. Workzone solves this by:

• Allowing detailed file/path-based reviewer assignments.
• Enforcing mandatory approvals to maintain quality.
• Automating merges once all conditions are met, saving time and reducing errors.

Use Case: Compliance in Regulated Industries

For companies in industries like healthcare or finance, regulatory compliance is critical. Workzone’s digital signature approvals and repository hooks ensure that every code change is approved and tracked with the highest standards, meeting ISO 27001 and CFR Part 11 requirements.

The post Workzone Cloud vs. Bitbucket .codeowners first appeared on Atlassian Apps for Efficient Teams.

Use Case 1: Small Company Scenario – A Creative Agency

Overview:
A creative agency with a team of 10 specializes in web design, branding, and digital marketing. The team uses Confluence for task planning, tracking client projects, and storing campaign resources.

Challenges Faced:

• Lack of a clear way to categorize project statuses across tasks.
• Confusion in identifying priority tasks.
• Inconsistent labelling of content on shared pages.

How Advanced Status Labels Help:

1. Streamlined Task Tracking
   • Use Case: The agency creates a “Status” category with labels like To Do, In Progress, Under Review, Completed.
   • Result: Team members can quickly see the status of each task at a glance, eliminating guesswork and saving time. Yes, sure you can type out the statuses manually, but for those of you keen on saving time, we offer you a simplified dropdown.
2. Prioritization of Tasks
   • Use Case: A “Priority” category is created with labels such as High, Medium, and Low.
   • Result: Urgent tasks are visually highlighted, enabling the team to focus on what matters most.
3. Department-Specific Labels
   • Use Case: Categories like Design, Marketing, and Development are created to group tasks by department.
   • Result: Team members can filter tasks relevant to their role, improving collaboration and reducing noise.

Benefits for the Agency:

• Enhanced visibility into project progress.
• Clear prioritization of client deliverables.
• Improved team communication with intuitive labels.

Future Potential:
The agency plans to use the search functionality to locate labels like “Under Review” to track bottlenecks in the review process and allocate resources more effectively.

Use Case 2: Enterprise Scenario – A Global Technology Company

Overview:
A technology enterprise with 2,000 employees operates globally, managing multiple software development teams, marketing initiatives, and customer support operations. They use Confluence as a central hub for documentation and project management.

Challenges Faced:

• Difficulty maintaining consistency across hundreds of projects.
• Lack of a unified system for tagging content across teams.
• Inefficient tracking of dependencies and deliverables.

How Advanced Status Labels Help:

1. Standardized Workflow Across Teams

• Use Case: The company sets up global categories like Status (e.g., Planned, In Progress, Blocked, Done) and Scope (e.g., Frontend, Backend, API, UX).
• Result: Teams across different departments follow consistent labelling practices, making it easier to understand and manage workflows across projects.

2. Enhanced Cross-Team Collaboration

• Use Case: Labels such as Dependent On and Requires Review are used to identify interdependencies and tasks requiring cross-functional input.
• Result: Teams can quickly identify blockers and coordinate more effectively, reducing delays.

3. Efficient Resource Allocation

• Use Case: Leadership uses the search functionality to locate all pages tagged with High Priority or Blocked.
• Result: Managers can focus resources on critical tasks, ensuring projects stay on track.

4. Compliance and Documentation

• Use Case: Compliance teams create categories like Regulatory Requirements and Approval Status, ensuring that tasks requiring regulatory oversight are clearly labeled.
• Result: The company reduces the risk of compliance issues and ensures audit readiness.

Benefits for the Enterprise:

• Scalable labeling system suitable for global operations.
• Improved transparency across teams and departments.
• Faster resolution of dependencies and blockers.

Future Potential:
The enterprise plans to integrate Advanced Status Labels with Jira to synchronize labels across platforms, enabling seamless collaboration between development and documentation teams.

Whether you’re a small agency or a global enterprise, Advanced Status Labels is designed to adapt to your needs.

We’re not here saying we have created the all new Jira for Confluence. But if you think this would align with your team’s current workflows, we welcome you to give Advanced Status Labels a try!

Visit Advanced Status Labels for Confluence on the Atlassian Marketplace and please do let us know what you think! We’re always looking to add new features & functionality.

Happy Labelling!

Sean Manwarring

Izymes

The post Advanced Status Labels for Confluence – Case Studies first appeared on Atlassian Apps for Efficient Teams.

But I know what you’re thinking, what happens when your Confluence pages are filled with status labels across multiple projects, teams, and workflows? How do you quickly find what you need without endless scrolling? Well, that’s where Advanced Status Labels Search comes in.

Introducing Status Labels Search: Find What You Need, Instantly

The Search functionality in Advanced Status Labels makes it easy for users to interact

• with status labels in Confluence. Instead of manually combing through pages to check on the status of a project, you can now:
• Instantly search for any label—no need to remember exact names or where they were placed.
• Combined status label search – list all pages with any combination of status labels.
• Filter by category, status, or keyword, making it easy to track progress across multiple pages.

Why is This a Game-Changer?

We all know Confluence is the go-to for documentation and collaboration, but as teams scale, finding relevant information becomes harder and harder. Advanced Status Labels’ Search ensures that tracking statuses across your Confluence spaces is effortless.

Let’s quickly dive into how it benefits different teams:

• Project Managers can quickly find all tasks labeled as “In Progress” without opening multiple project pages.
• Compliance Teams can search for “Approval Pending” items across all documentation to ensure regulatory requirements are met.
• Developers can locate all tasks in status “Blocked” in one place to address dependencies efficiently.

Use Case: A Real-World Scenario

Imagine you’re managing a product launch with dozens of moving parts—design, development, marketing, and QA all working together. You’ve categorized tasks using Advanced Status Labels:

• “Feature Ready for QA” in Development
• “Campaign in Progress” in Marketing
• “Legal Approval Pending” in Compliance

Instead of digging through multiple pages, simply search the exact status label you are after in Search. You now have a consolidated view of everything moving forward across teams. No confusion, no time wasted.

What’s Next?

The Search feature is just one step towards making Confluence more intuitive and efficient. Future enhancements will include advanced filters, reporting, and analytics, giving you deeper insights into your projects at a glance.

Stay tuned for our next blog post, where we’ll explore how the Label Manager brings even more control and customization to your workflows.

You can find Advanced Status Labels for Confluence on the Atlassian Marketplace here

We would love to hear your thoughts and feedback either in the comments below or get in touch with our support channel here!

Until next time,

Sean & Ulrich from the Izymes Team

The post Unlocking the Power of Search in Advanced Status Labels for Confluence first appeared on Atlassian Apps for Efficient Teams.