Multi-User Collaboration

When two people open the same flag in two browsers, A vs B keeps both tabs in sync without losing anyone's work. The page subscribes to a live channel for the flag, and every published change shows up in every open tab within a few seconds.

How it works

While a flag detail page is open, your browser holds a live connection to A vs B. As soon as anyone (yourself in another tab, or a teammate) publishes a change to that flag, that change is pushed to every open tab. Your tab fetches the new published snapshot and reconciles it against your draft.

If the live connection cannot be opened or drops (an older proxy, a restrictive corporate network, a flaky connection), the page falls back to checking for changes every 30 seconds until the connection comes back. The user-visible behavior is the same: banners just appear up to 30 seconds later instead of within a few seconds. The fallback pauses while the tab is in the background, so a tab you left open somewhere is not quietly working away.

Clean updates

When the remote change does not touch any rule you have edited, your tab silently rebases. Your in-flight changes stay exactly as you left them, and any rules you had not touched pick up the remote edit automatically. A short cyan banner confirms what happened:

"This flag was updated by Alice 1 minute ago. Your changes are preserved."

The banner auto-dismisses after eight seconds. You can also click Dismiss to clear it immediately.

Conflicts

When the remote change touches the same rule you are editing (or removes a rule you have edited, or changes the env config in a way that conflicts with your env-config edit), the page surfaces an amber conflict banner instead and disables Save draft and Save & publish until you resolve it:

"This flag was updated by Bob 30 seconds ago and 2 of your changes conflict."

Click Resolve conflicts on the banner to open a three-column picker. Each affected rule is shown side by side:

• Mine: the version you have in your local draft. Pick this to keep your edit; the rule will be marked dirty and included in the next publish.
• Theirs: the rule as it now exists in the published snapshot. Pick this to drop your local edit and adopt what is currently live.
• Result: a preview of what the rule will look like after you apply your selection. Updates live as you toggle.

Whole-flag fields (the environment's enabled state, default variation, scheduling) appear in a single "Environment settings" row above the per-rule rows so the same picker handles them. Every column names variations by their names, not by internal ids.

Some rules exist on one side only, and each says what your choice does:

• A rule you added in this tab is kept whichever side you choose. It never conflicts.
• A rule they deleted that you edited: choosing yours adds it back as a new draft rule; choosing theirs drops it.
• A rule only they have: choosing theirs keeps it; choosing yours deletes it when you publish.

"Theirs" always means the published version, exactly as the other person left it.

Two shortcut buttons in the header let you take everything from one side at once: Keep all mine and Take all theirs. Clicking Apply resolution commits the selection to your local draft, clears the conflict banner, and re-enables the bottom bar so you can publish.

• The amber banner appears when a teammate's published change touches a rule you were already editing.
• Each affected rule shows your version, their version, and a live preview of what publishing will produce.
• Use these two buttons to take everything from one side at once, instead of picking rule by rule.

What counts as a conflict

• You and the remote both edited the same rule: any change to name, key, traffic allocation, variation distribution, audiences, metrics, exclusion groups, stats engine, conclude state, or per-rule overrides.
• The remote deleted a rule you were editing.
• You and the remote both changed the environment config in observable ways (enabled flag, default variation, scheduling).

Adding a brand-new rule locally is never a conflict: your new rule keeps its temporary id and rides through Save & publish like any other diff. Edits to different rules are never a conflict: each side's changes apply independently.

Who is editing right now

The conflict banner names the publisher whenever they are a member of your organization. If the publisher is no longer a member or the lookup fails, the banner falls back to "someone".

Live presence

While anyone in your organization has a flag's detail page open and a rule open in the right-side panel, their avatar appears next to that rule's name in the rule list. Hover the avatar to see their name and how recently they were active:

"Alice Anderson is editing this rule (active 8s ago)"

The page sends a heartbeat every thirty seconds while it is open and in view, and the avatar disappears within a couple of minutes of someone closing their tab or stepping away. A teammate who leaves the page open but stops using it for ten minutes also fades out until they are active again. You will not see your own avatar, only teammates'.

When several teammates are looking at the same rule, their avatars stack with a small overlap. If more than three are on the same rule, an extra +N chip appears after the first three.

Per-rule lock

When you open a rule in the right-side panel, A vs B acquires an editing lock for that rule. The lock's holder is the only person who can edit the form; everyone else opening the same rule sees a read-only view with a banner naming the holder and offering a Request edit button. The lock holder's avatar in the rule list gains a green ring with a small lock badge so the ownership is visible at a glance.

• Anyone with this flag open shows up next to the rule they are looking at.
• A green ring with a lock badge means that teammate is the one who can currently edit the rule.
• Ask for a turn with Request edit. The current holder gets a toast and a banner, and the lock passes to you automatically once they close or save.

How the lock moves around

• Acquire: opening the rule panel acquires the lock if no one else holds it. Closing the panel releases it.
• Refresh: your tab pings the server every thirty seconds while the panel is open. Every refresh extends the lock's expiry to five minutes from now.
• Expire: if your tab stops refreshing (closed unexpectedly, lost network, browser crash), the lock expires five minutes after the last refresh. Other tabs see the rule become available shortly after that.
• Take over: one minute past expiry the lock can be force-claimed by anyone with edit permission. Their banner shows a Take over button; clicking it transfers ownership.

Requesting edit access

While someone else holds the lock, the read-only banner offers Request edit. Clicking it does two things: a toast appears on the holder's tab telling them you want the rule, and their banner gains a persistent " is waiting to edit this rule" line that stays visible until they release. Your tab flips into a waiting state with a Cancel affordance: click it any time to remove yourself from the queue. When the holder closes the panel or saves their changes, your tab automatically picks up the lock and becomes editable.

If your lock disappears mid-edit

On the rare occasion that you held a lock but lost it (your network was down long enough for the lock to expire and someone took over), a red banner appears: "Lock lost. Another teammate is now editing this rule. Reload to see their changes." The form is disabled until you reload to avoid silently overwriting their edit.