One-Way vs Two-Way Group Sync: Choosing a Source of Truth
SyncMyGroup team · October 26, 2026
Every group sync has to answer one question before it does anything useful: when two systems disagree about who belongs in a group, which one is right?
One-way sync answers it once, up front. Two-way sync answers it on every change. Both are legitimate. But most of the problems teams hit with group sync — people mysteriously reappearing, removals that don't stick, flapping memberships — come from choosing two-way when one-way would have done, or from never choosing at all.
This post explains how each mode behaves, where each one fits, and a practical way to decide per group.
One-way sync
In a one-way sync, one system is the source and the other is the destination. The destination is rebuilt to match the source. Anything in the destination that the source doesn't have is removed; anything missing is added.
engineering@ (Google) ──▶ @engineering (Slack)
Properties:
- Predictable. At any moment, the destination should equal the source, plus configured exceptions. You can reason about it without looking at history.
- Self-healing. If someone edits the destination by hand, the next sync reverts it. Drift can't accumulate.
- Easy to audit. "Who has access?" is answered by looking at the source.
- Rigid. Anyone who needs a change has to make it in the source, even if they live in the destination tool all day.
The rigidity is the point. It's what makes one-way sync safe for access-bearing groups.
Two-way sync
In a two-way (bidirectional) sync, both systems can change membership, and changes on either side are carried to the other.
team-design@ (Google) ◀──▶ @design (Slack)
Properties:
- Flexible. People can maintain the group wherever they work.
- Needs conflict rules. If one side adds someone and the other removes them at about the same time, something has to decide.
- Deletes are ambiguous. If a person is missing on one side, were they removed there, or were they never added? A two-way sync has to tell the difference, usually by tracking state between runs.
- Harder to audit. The answer to "who added this person?" might be in either system.
Two-way sync doesn't remove the need for a source of truth. It spreads it across two systems, and you have to understand how it resolves disagreements.
The failure modes
These are what go wrong when the direction isn't chosen deliberately.
Flapping
Two systems both believe they own the group. System A adds Priya; a separate process on system B removes her because she's not in B's source. Next cycle, A adds her back. Her membership flips every run, and she gets join and leave notifications all day.
The usual cause isn't a two-way sync. It's two one-way syncs pointing at the same destination from different sources: an IdP's SCIM push and a sync tool, or two sync jobs set up by different people.
Removals that don't stick
An admin removes a leaver from the Slack handle. The handle is the destination of a one-way sync from a Google Group that still contains them. Next cycle, they're back. The admin removes them again. This continues until someone fixes the Google Group.
The sync is behaving correctly. The fix is in the source, and everyone who edits groups needs to know which side that is.
Accidental mass changes
In a two-way sync, a mistake on either side propagates. Someone bulk-removes thirty people from a Slack user group while cleaning up, and the sync dutifully removes them from the Google Group as well — and from anything downstream of that Google Group.
Chains
Google → Slack, then Slack → Linear, then Linear → something else. Each link is fine on its own. Chained together, a delay or error at the start passes through every link, and it's hard to tell where a membership came from. Prefer a hub: one source, many destinations, each derived directly.
Prefer: Avoid:
engineering@ ─▶ @engineering engineering@ ─▶ @engineering
├─▶ #engineering └─▶ Linear team
├─▶ Linear team └─▶ ...
└─▶ GitHub team
When to use each
| Situation | Direction | Source |
|---|---|---|
| Group grants access (repos, projects, private channels) | One-way | Directory (Google / Entra ID) |
| Department or HR-driven group | One-way | Directory |
| On-call handle | One-way | Schedule (PagerDuty / Opsgenie / JSM) |
| Team-maintained group that lives in Slack | One-way | Slack user group |
| Project team where engineers self-organise in Linear or GitHub | One-way | Linear team / GitHub team |
| Small team that genuinely edits in two places, low risk | Two-way | Both, with clear rules |
Notice that "the source is the tool people actually edit" covers most cases without two-way sync. If your design team curates @design in Slack, make Slack the source and sync to Google. That's one-way, in the less obvious direction, and it gives the flexibility people wanted without ambiguity.
Two-way sync is the right answer when both sides really are edited by the people who own the group, the group doesn't grant sensitive access, and you've understood how the tool handles conflicts and deletions.
Choosing a source: four questions
For each group, ask:
- Where do joiners and leavers get processed? If the answer is "the directory, via HR," that's your source for anything access-related.
- Who actually edits this group today? If it's the team in Slack, fighting that habit is harder than syncing from it.
- What does membership grant? The more it grants, the stronger the case for a directory source and one-way sync.
- What happens if it's wrong for an hour? For an on-call handle, a lot. For a social channel, very little. The higher the stakes, the simpler the direction should be.
Write the answer down somewhere the team can find it: a table of group, source, direction and owner. It's the single most useful piece of documentation for a group sync setup.
Exceptions without two-way sync
A common reason teams reach for two-way sync is exceptions: "but the CTO needs to be in #incidents and isn't in the source." That's not a direction problem. It's an exception.
Handle exceptions explicitly on the destination: a list of people who stay regardless of the source, and a list of people or groups the sync never touches. Then the direction stays one-way, and exceptions are visible rather than hidden as manual edits.
How SyncMyGroup handles direction
SyncMyGroup lets you choose the direction of each mapping: Google → Slack, Slack → Google, GitHub → Linear, PagerDuty → Slack, and so on across the tools it connects. Each sync team is one source and one destination, so the source of truth is explicit for every group.
The features that matter for direction:
- Preview before any change, so you can see what a sync will do in the chosen direction — including removals — before anything is written.
- Permanent users for exceptions, so one-way syncs can still keep people the source doesn't have.
- Filters and exclusions for groups and users the sync should never touch.
- Change notifications with
@SyncMyGroups subscribe <team>, in Slack or Microsoft Teams, so every add and remove is visible.
If you set up syncs in both directions for the same pair, test it on a non-critical group first and use the preview to confirm how changes on each side are carried across.
For examples of common directions, see 12 group sync workflows and the full workflow list. For the joiner and leaver side, see automating onboarding into Slack groups and offboarding: removing users from groups.
A starting configuration
If you're setting up group sync for the first time, this default works for most teams:
- Directory → everything for departments and access groups, one-way.
- Schedule → Slack for on-call handles, one-way.
- Slack → directory for the few teams that genuinely curate their group in Slack, one-way.
- Two-way only after you've run one-way for a while and found a specific group where it's needed.
- One writer per destination, always. If an IdP's SCIM already writes a group, don't point a sync tool at it too.
FAQ
Is two-way sync less safe than one-way?
It isn't unsafe, but it has more ways to surprise you. Mistakes on either side propagate, and deletions have to be inferred. For groups that grant access, one-way from a directory is easier to audit and reason about.
What's the difference between two-way sync and two one-way syncs?
A two-way sync is one process that tracks state on both sides and resolves conflicts. Two one-way syncs pointing at each other, or at the same destination, are two processes that don't know about each other. The second setup is the usual cause of flapping memberships.
Can I change the direction later?
Yes. Before switching, make sure the new source is complete, because the first run in the new direction will remove anything the new source doesn't have. Read the preview carefully.
Where should exceptions live?
On the destination, as an explicit list of people who stay regardless of the source. That keeps the direction one-way and makes exceptions easy to review.
Pick one group, decide its source, and preview the sync in SyncMyGroup. It's free up to 5 users; Starter is $2/user/month. See pricing.