Clarify how "Only impacted by breaking changes" interacts with workspace approval by logason · Pull Request #1736 · avohq/docs

logason · 2026-08-10T21:14:50Z

Follow-up to #1733, prompted by a customer question: "If we have 'Require approval from owning stakeholders' enabled at a workspace level, how does the stakeholder setting 'Only impacted by breaking changes' work?"

Two changes

1. Fixes an inaccuracy in #1733. That PR described Only impacted by breaking changes as leaving the team out of the impacted list. It does not. ignoreNonBreakingImpactsForReview is only read by GetSpecificDomainRequiredReviewersUseCase — the impacted-stakeholders list still shows the team (GetImpactedDomainsUseCase deliberately does not tier-filter, so the UI can render it), BranchBar__Dropdown adds per-item Breaking / Non-breaking labels for exactly these teams, and ShouldSendDomainNotificationUseCase never reads the setting, so Slack notifications are unaffected.

2. Documents the interaction with the workspace setting, which the guide did not cover:

The workspace setting decides who is pulled in — it ORs into shouldRequireReview for impacted owner teams only, overriding their own notification setting. Stakeholder-but-not-owner teams still follow their own setting.
The team setting decides whether the change counts as impact — passesNonBreakingFilter is ANDed after, for both the owner and stakeholder buckets, so it applies even under the workspace requirement.
For an owner team the filter reads maxOwnerTier — only owned items count. A team owning a Non-breaking change and merely stakeholding a Breaking one is not required to review.

Note for the product team

The in-product copy under the workspace toggle says "This overrides individual stakeholder review settings". That holds for the notification setting (a #doNothing choice is overridden for owners) but not for Only impacted by breaking changes, which still filters. Worth a follow-up ticket to narrow that sentence.

yarn spellcheck passes on the changed file.

🤖 Generated with Claude Code

Summary by CodeRabbit

Documentation
- Clarified how the “Only impacted by breaking changes” setting affects team review requirements.
- Explained that excluded teams remain listed as impacted stakeholders and continue receiving change labels and Slack notifications.
- Documented how workspace- and team-level settings combine to determine review requirements, including owner-specific behavior.

…ace approval Two corrections to the section added in #1733: - The setting was described as leaving the team out of the impacted list. It does not — the team still appears in the impacted stakeholders list (with per-item Breaking / Non-breaking labels) and Slack notifications are unaffected. It gates the required-reviewer decision only. - Adds the interaction with the workspace-level "Require approval from owning stakeholders", which customers ask about: the workspace setting decides who is pulled in (owners only, overriding their own notification setting), the team setting decides whether the change counts as impact, and both must pass. Also notes that for an owner team only owned items count towards the breaking/non-breaking decision. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

vercel · 2026-08-10T21:14:56Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 10, 2026 9:16pm

coderabbitai · 2026-08-10T21:15:35Z

📝 Walkthrough

Walkthrough

The guide now states that the breaking-only setting excludes teams from required review without removing them from the impacted stakeholder list. It also documents workspace-level approval requirements and owner-specific behavior.

Changes

Stakeholder review settings

Layer / File(s)	Summary
Clarify review eligibility rules `pages/data-design/guides/managing-changes-impacting-multiple-stakeholders.mdx`	The guide clarifies required-review eligibility, impacted stakeholder listing, approval requirements, labels, Slack notifications, and owner-specific impact evaluation.

Estimated code review effort: 2 (Simple) | ~5 minutes

Possibly related PRs

avohq/docs#1733: Both PRs clarify the “Only impacted by breaking changes” setting in the stakeholder-impact guide.

Poem

I’m a rabbit with a guide to mend,
Breaking rules now clearly bend.
Teams stay listed, reviews stay right,
Owners know when to grant the light.
Slack labels hop in perfect flight.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main documentation change about how “Only impacted by breaking changes” interacts with workspace approval.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch docs/breaking-changes-setting-vs-workspace-approval

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

pages/data-design/guides/managing-changes-impacting-multiple-stakeholders.mdx

Parsing error: Unexpected token (4:0)

_{Comment @coderabbitai help to get the list of available commands.}

logason · 2026-08-10T21:16:23Z

📝 Changed routes:

…-multiple-stakeholders
^{(view full size)}

Commit 7d2797b (https://docs-o60n9cb8s-teamavo.vercel.app).

coderabbitai

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@pages/data-design/guides/managing-changes-impacting-multiple-stakeholders.mdx`:
- Around line 108-110: Update the wording around the team setting to distinguish
impacted-stakeholder list membership from required-review eligibility: replace
unqualified claims that the setting determines whether a change counts as impact
with wording about required-review eligibility. Revise the statement around
“regardless of their individual settings” to clarify that workspace requirements
do not override a team’s “Only impacted by breaking changes” setting, including
the guidance in the section around the owner-team example.
- Around line 105-107: Revise the introductory “both say yes” sentence so it
applies only to impacted owner teams. Explicitly state that stakeholder-only
teams are governed by their own “When impacted as stakeholder” setting
regardless of the workspace approval setting, while preserving the existing
owner-team explanation.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: d74a53de-6d78-45de-a05e-1c5a78db5051

📥 Commits

Reviewing files that changed from the base of the PR and between c259b61 and 7d2797b.

📒 Files selected for processing (1)

pages/data-design/guides/managing-changes-impacting-multiple-stakeholders.mdx

coderabbitai · 2026-08-10T21:18:53Z

+The workspace setting and the team setting answer different questions, and a team is only required to review when both say yes.
+
+- **The workspace setting decides who is pulled in.** With it enabled, every impacted *owner* team is added as a required reviewer, regardless of what that team chose in its own notification settings. It does not apply to teams that are stakeholders but not owners – those still follow their own **When impacted as stakeholder** setting.


🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Scope the “both say yes” rule to owner teams.

Line 105 makes the workspace setting a prerequisite for every team. The workspace requirement applies only to impacted owner teams. A stakeholder-but-not-owner team follows its When impacted as stakeholder setting even when workspace approval is disabled. Rewrite the sentence to state this distinction explicitly.

Proposed wording

- The workspace setting and the team setting answer different questions, and a team is only required to review when both say yes. + For an impacted owner team, the workspace setting and the team setting must both allow required review. A stakeholder-but-not-owner team follows its `When impacted as stakeholder` setting.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

The workspace setting and the team setting answer different questions, and a team is only required to review when both say yes.

- **The workspace setting decides who is pulled in.** With it enabled, every impacted *owner* team is added as a required reviewer, regardless of what that team chose in its own notification settings. It does not apply to teams that are stakeholders but not owners – those still follow their own **When impacted as stakeholder** setting.

For an impacted owner team, the workspace setting and the team setting must both allow required review. A stakeholder-but-not-owner team follows its `When impacted as stakeholder` setting.

- **The workspace setting decides who is pulled in.** With it enabled, every impacted *owner* team is added as a required reviewer, regardless of what that team chose in its own notification settings. It does not apply to teams that are stakeholders but not owners – those still follow their own **When impacted as stakeholder** setting.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pages/data-design/guides/managing-changes-impacting-multiple-stakeholders.mdx` around lines 105 - 107, Revise the introductory “both say yes” sentence so it applies only to impacted owner teams. Explicitly state that stakeholder-only teams are governed by their own “When impacted as stakeholder” setting regardless of the workspace approval setting, while preserving the existing owner-team explanation.

coderabbitai · 2026-08-10T21:18:53Z

+- **The team setting decides whether the change counts as impact in the first place.** If a team has *Only impacted by breaking changes* enabled and the branch only makes Non-breaking changes to its items, the team is not required to review – even under the workspace requirement.
+
+In short: the workspace setting makes review the default for owning teams across all changes, and each team can narrow that to breaking changes only. Note that for an **owner** team, only the items it *owns* count towards that decision. A team that owns an item receiving a Non-breaking change, and is merely a stakeholder on another item receiving a Breaking one, is not required to review.


🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Keep impacted-list membership separate from required-review eligibility.

Line 108 says the team setting decides whether a change counts as impact in the first place. Line 100 says the team remains in the impacted stakeholders list. Replace the unqualified “impact” wording with “required-review eligibility.” Also update Lines 171-175, where “regardless of their individual settings” must not bypass Only impacted by breaking changes.

Proposed wording

- The team setting decides whether the change counts as impact in the first place. + For required-review eligibility, the team setting decides whether a change qualifies the team for required review.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pages/data-design/guides/managing-changes-impacting-multiple-stakeholders.mdx` around lines 108 - 110, Update the wording around the team setting to distinguish impacted-stakeholder list membership from required-review eligibility: replace unqualified claims that the setting determines whether a change counts as impact with wording about required-review eligibility. Revise the statement around “regardless of their individual settings” to clarify that workspace requirements do not override a team’s “Only impacted by breaking changes” setting, including the guidance in the section around the owner-team example.

vercel Bot deployed to Preview August 10, 2026 21:16 View deployment

coderabbitai Bot requested changes Aug 10, 2026

View reviewed changes

Navigation Menu

Uh oh!

Clarify how "Only impacted by breaking changes" interacts with workspace approval - #1736

Clarify how "Only impacted by breaking changes" interacts with workspace approval#1736
logason wants to merge 1 commit into
mainfrom
docs/breaking-changes-setting-vs-workspace-approval

logason commented Aug 10, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

vercel Bot commented Aug 10, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented Aug 10, 2026 •

edited

Loading

Walkthrough

Changes

Uh oh!

logason commented Aug 10, 2026

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot Aug 10, 2026

Uh oh!

coderabbitai Bot Aug 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

		The workspace setting and the team setting answer different questions, and a team is only required to review when both say yes.

		- The workspace setting decides who is pulled in. With it enabled, every impacted owner team is added as a required reviewer, regardless of what that team chose in its own notification settings. It does not apply to teams that are stakeholders but not owners – those still follow their own When impacted as stakeholder setting.

		- The team setting decides whether the change counts as impact in the first place. If a team has Only impacted by breaking changes enabled and the branch only makes Non-breaking changes to its items, the team is not required to review – even under the workspace requirement.

		In short: the workspace setting makes review the default for owning teams across all changes, and each team can narrow that to breaking changes only. Note that for an owner team, only the items it owns count towards that decision. A team that owns an item receiving a Non-breaking change, and is merely a stakeholder on another item receiving a Breaking one, is not required to review.

Uh oh!

Conversation

logason commented Aug 10, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Two changes

Note for the product team

Summary by CodeRabbit

Uh oh!

vercel Bot commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai Bot commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Uh oh!

logason commented Aug 10, 2026

📝 Changed routes:

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

logason commented Aug 10, 2026 •

edited by coderabbitai Bot

Loading

vercel Bot commented Aug 10, 2026 •

edited

Loading

coderabbitai Bot commented Aug 10, 2026 •

edited

Loading