Change reviews and approvals
Two gates, deliberately: the branch, then each consumer.
By the OneEnv team · Last updated
Two gates
Gate 1, the branch. Submitting creates one review notification. An Owner or Admin chooses Approve & merge or Reject, with an optional reason. Approval applies every change in one transaction. Rejection changes nothing.
Gate 2, each consumer. After a merge, every service that inherits something that changed receives its own decision. Approving advances that service to the new value. Rejecting leaves it on the previous value.
Why two gates
The first gate is about whether the change should exist. The second is about whether each consumer can take it now. A reviewer cannot know every consumer's constraints; the owning service can.
What the reviewer sees
- Per-domain summary of what changed.
- An impact matrix: before merge, a preview of which services would be notified; after merge, their real statuses.
- A readiness score that drops for conflicts, breaking changes and unresolved impacts.
- Other open branches that touch the same items.
Who can do what
- Any member can create a branch. The creator, or an Owner or Admin, can submit it.
- Only an Owner or Admin can approve or reject the branch.
- A service's pending change is approved or rejected by someone with
service_adminon that service, or by an Owner or Admin. - The service that staged the original change is approved automatically; it already agreed.
What approve and reject do per domain
- Env value: approve moves the service to the new value; reject keeps the old one.
- Column added: approve gives the service the column; reject does not.
- Column removed: approve removes the column from the service; reject keeps it (non-destructive).
- API route changed: approve re-syncs the service's copy; reject marks it diverged. Route removed: approve removes the link; reject keeps it.
- Validation rule changed: approve re-syncs the rule copy; reject diverges.