Bitbucket Data Center Reviewer Groups: When Native Groups Are Enough—and When Workzone Helps
Bitbucket Data Center Reviewer Groups: When Native Groups Are Enough—and When Workzone Helps
Bitbucket Data Center already has useful native reviewer groups. Project and repository admins can create reusable reviewer groups, add those groups to pull requests, use them as default reviewers, and—on modern Bitbucket versions—reference reviewer groups in CODEOWNERS.
The management problem appears when the people in those groups change frequently.
Native reviewer groups are maintained at project or repository level. If your organisation already manages team membership centrally in an external directory such as Microsoft Active Directory, maintaining another reviewer-group membership list in Bitbucket can create duplicate administration.
Workzone for Bitbucket Data Center can use directory-backed groups as pull request reviewer groups, as well as native Bitbucket reviewer groups. That lets teams reuse centrally managed membership and then add Workzone-specific rules such as branch/file-based reviewer assignment, group approval quotas and mandatory reviewer groups.
Scope note: this article is about Bitbucket Data Center and Workzone’s Data Center reviewer-group model. Bitbucket Cloud has a different group and CODEOWNERS model.
Key Takeaways
- Native Bitbucket Data Center reviewer groups are much more capable than they were when this article was first published in 2023.
- Bitbucket 9.0 added reviewer groups as code owners, and Bitbucket 9.5 added reviewer groups as default reviewers.
- Native reviewer groups are still project/repository-managed reviewer-group objects.
- Workzone can use Active Directory-backed groups or native Bitbucket reviewer groups and combine them with branch, file/path and approval rules.
- If native reviewer groups already meet your needs, there is no reason to add Workzone solely for group creation.
What Native Bitbucket Reviewer Groups Can Do Today
Bitbucket Data Center reviewer groups have existed since version 7.13. Project and repository administrators can create a named group and add Bitbucket users who already have access to that project or repository.
Current Bitbucket Data Center also supports two important capabilities that were not available when the original version of this article was written:
- Reviewer groups as code owners: from Bitbucket 9.0, a CODEOWNERS rule can reference reviewer groups and choose all or a selected number of members as code owners.
- Reviewer groups as default reviewers: from Bitbucket 9.5, existing reviewer groups can be selected in a default-reviewer rule so their members are automatically added to matching pull requests.
Native Bitbucket can therefore solve many common reviewer-group workflows without an app.
If the requirement is simply:
“For this repository or branch, automatically add this predefined group of reviewers.”
start with Bitbucket’s native reviewer groups and default-reviewer functionality.
Where the Membership-Maintenance Problem Still Exists
The important distinction is between a Bitbucket reviewer group and an organisation’s existing directory group.
Bitbucket Data Center can connect to external user directories including Microsoft Active Directory and other LDAP directories. That allows users and groups to be managed centrally in the organisation’s directory.
Native reviewer groups, however, are still created and managed as reviewer groups at project or repository level.
For an organisation with many repositories, that can mean maintaining overlapping structures:
- Active Directory: who currently belongs to the Backend, QA or Security team;
- Bitbucket reviewer groups: which of those users are listed in the relevant project/repository reviewer group.
When someone joins a team, changes role or leaves the organisation, centrally managed directory membership is already being updated.
The question is whether you also want administrators to maintain separate reviewer-group membership lists across Bitbucket.
How Workzone Uses Active Directory Groups
Workzone Data Center can use Active Directory groups and native Bitbucket repository reviewer groups in its reviewer configuration.
Instead of defining a rule around a fixed list of individual users, a Workzone rule can reference the relevant directory-backed team.
For example:
| Changed code / branch | Reviewer group | Required approvals |
|---|---|---|
src/ui/** | ui-devs | 1 |
src/main/** | backend-devs | 2 |
src/test/** | qa-team | 1 |
If the organisation updates membership of backend-devs in its directory, the reviewer rule continues to reference that group rather than requiring the Workzone rule itself to be rewritten with individual names.
This is the part of the original 2023 article that still matters most:
centralise team membership where your organisation already manages it, then reuse that membership in the pull request workflow.
What Workzone Adds Beyond Group Membership
The stronger reason to use Workzone today is not merely that it understands groups.
Native Bitbucket does too.
Workzone adds more policy around those groups, including:
- reviewer groups selected by source and destination branch;
- file and directory patterns that only add a group when its code area changes;
- an explicit approval quota for each reviewer group;
- mandatory reviewer groups;
- group approvals that can participate in Workzone merge conditions;
- other controls such as successful-build requirements, independent-review rules and digitally signed approvals where configured.
For example, there is an important difference between:
“Add the Security team to this pull request.”
and:
“If files under
security/**change, add the Security group and require two eligible approvals from that group before the pull request can merge.”
The first requirement may be handled natively.
The second is the type of granular approval policy Workzone is designed to express.
Native Reviewer Groups vs Workzone
| Requirement | Native Bitbucket Data Center | Workzone Data Center |
|---|---|---|
| Create reusable reviewer groups | Yes | Yes |
| Use reviewer groups as default reviewers | Yes, in modern Bitbucket versions | Yes |
| Use reviewer groups in CODEOWNERS | Yes, from Bitbucket 9.0 | Workzone uses its own branch/file reviewer rules |
| Reference Active Directory groups directly in reviewer rules | Native reviewer groups are separately managed at project/repository scope | Yes |
| Require approvals from a particular reviewer group | Native default-reviewer rules can require an approval count | Yes, including explicit group-specific quotas |
| Apply reviewer groups only for matching files/directories | CODEOWNERS can map reviewer groups to changed paths | Yes, with file/path-specific approval quotas |
| Mandatory group / richer merge-policy controls | Use native reviewer and merge-check capabilities | Yes, with Workzone-specific reviewer and merge conditions |
An Operational Detail for Large Directory Groups
Directory groups can be much larger than a sensible pull-request review team.
Workzone therefore has a configurable Reviewer group size limit.
The current Data Center documentation lists a default of 20 users per reviewer group to avoid accidentally adding every member of a very large Active Directory group to one pull request.
Izymes recommends using focused groups such as java-devs or qa-ui rather than broad organisational groups containing hundreds of people.
This is worth designing deliberately: directory-backed reviewer groups reduce maintenance, but they should still represent a meaningful review audience.
When Native Bitbucket Reviewer Groups Are Enough
You probably do not need Workzone just for reviewer groups if:
- your reviewer groups are stable and easy to maintain;
- project/repository-level groups are the right scope;
- native default-reviewer rules or CODEOWNERS already route reviews correctly;
- a general approval count is sufficient for your merge policy.
Consider Workzone when the real problem is broader than creating a group—for example, reusing centrally managed AD groups, applying file/path-specific group approval quotas, or enforcing more detailed reviewer and merge rules.
Bottom Line
The answer to “How do I solve Bitbucket reviewer groups?” has changed since 2023.
Native Bitbucket Data Center is now a good solution for many reviewer-group workflows. It supports reviewer groups, default reviewer groups and reviewer groups as code owners.
Workzone is useful when an organisation wants to go a step further:
reuse directory-backed team membership and turn those groups into granular review and approval policy.
That avoids maintaining individual reviewer lists in multiple places while still letting the pull request workflow decide which team needs to review, when they need to review, and how many approvals are required.
Want to Configure Reviewer Groups in Workzone?
See the Workzone Data Center reviewer groups documentation, file and module reviewer guide, and global reviewer-group settings.
You can also view Workzone for Bitbucket Data Center on the Atlassian Marketplace.
By Sean Manwarring, Head of Marketing at Izymes
Published 15 November 2023 · Updated 19 October 2026
