OneEnv
Use case

Shared configuration change approval

A realistic walk through changing one shared value that twelve services read, exactly as OneEnv implements it today.

The workflow

Stage
edit lands on a branch
→
Submit
one review notification
→
Merge
Owner/Admin approves
→
Fan-out
one impact per service
→
Per-service decision
approve / reject

1. A developer proposes a change

Editing a governed value — say PAYMENT_API_VERSION from v1 to v2 — does not touch the shared value. It stages a change on the developer's active branch, similar to a commit on a pull request. If someone else changed the same value in the meantime, OneEnv detects the conflict at merge time and requires a rebase rather than overwriting.

2. Reviewers see what would be affected

Submitting the branch creates a single review notification. The Change Review Center shows the diff, a readiness score, an impact preview of which services would be notified, and whether any change is flagged as breaking.

3. An Owner or Admin merges

Approving the review merges the branch: the shared value is updated and one notification is fanned out, with an impact row for every service that currently inherits it. Each notification carries a computed 0–100 impact score and a risk level (low, medium, high, critical) based on reach, breaking-change signals, secret sensitivity and whether anyone can act on it.

4. Each service approves or rejects

Every affected service sees the exact old and new value. A holder of service_admin on that service (or a workspace Owner/Admin) approves or rejects independently. Approving advances that service's resolved value; rejecting leaves it on the last value it approved. Nothing is forced.

Outcome for one serviceWhat its export serves
ApprovedThe new value, from that moment.
RejectedThe previous approved value; the rejection is recorded and the impact can be resynced later.
Not yet decidedThe previous approved value.

5. State and history are updated

The merged branch is the permanent record of the change. Approvals, rejections, resyncs and override publishes are written to an append-only audit trail you can filter and search, and a merged branch can be reverted through the same review path.

Limits worth knowing
Branch review is an Owner/Admin decision on the whole branch, not a per-service one — the per-service step happens after the merge. There is no automatic rollout to running systems; services pick up approved values through the export your pipeline consumes.

Background: the branch and merge engine and governance visibility.