Every organization with more than a few dozen employees has the same problem. User identities are scattered across systems that do not talk to each other.
The primary directory holds the canonical employee record. Google Workspace has its own user database. Microsoft 365 maintains a separate identity store. Your line-of-business applications each have their own user tables. And somewhere in the middle, a help desk technician is manually copying data between systems, hoping they do not make a typo.
This is the identity fragmentation problem. I have spent years building systems to solve it.
The Real Cost of Fragmentation
When someone joins your organization, they need accounts in multiple systems. When they leave, those accounts need to be disabled everywhere. When they change their password, that change should propagate. When they move departments, their permissions should update.
In a fragmented environment, each of these events requires manual intervention in multiple places. A new hire means five separate account creations. An offboarding means hunting through every system to make sure access was revoked. A password reset means walking the user through three different change dialogs.
The labor cost is obvious. Less obvious is the security cost. Orphaned accounts in forgotten systems become attack vectors. Password policies cannot be enforced consistently. Access reviews require pulling reports from a dozen sources and correlating them manually.
Most organizations do not realize how bad the problem is until they fail an audit or discover a former employee still had active access six months after leaving.
The Source of Truth Problem
The first instinct is usually to pick a winner. Make the primary directory the canonical source. Or make your HR system the master record. Everything else syncs from there.
This works until it does not. Different systems have different data models. AD does not know about Google organizational units. Google does not understand AD nested group memberships. Your HR system has fields that neither directory cares about.
One-way sync creates a different kind of fragmentation. Now you have authoritative data in one place and stale copies everywhere else. The copies drift. Edge cases accumulate. Someone makes a temporary change directly in a downstream system, and now your sync is in conflict.
The solution is not picking a winner. It is building a layer that understands all the systems and manages the relationships between them.
The Orchestration Layer
The solution is an orchestration layer that sits above the individual identity stores and treats them as endpoints rather than sources. The dashboard maintains its own record of what each user state should be across all systems. Changes flow through the dashboard, which then pushes updates to each connected system.
This inverts the typical model. Instead of systems syncing to each other, they all sync to a central orchestrator. The orchestrator knows the mapping between systems and handles the translation.
A password change becomes a single action. The user changes their password in the dashboard. The dashboard updates the primary directory, then Google, then M365, then any other connected system. The user does not know or care that multiple systems are involved.
An offboarding becomes a single click. Disable the user in the dashboard, and every connected account is suspended simultaneously. No hunting through systems. No checklist of manual steps.
Sync Flags and Conflict Resolution
The tricky part is handling systems that can be authoritative for different attributes. Maybe HR owns the employee department and title. Maybe the primary directory owns their group memberships. Maybe Google owns their email aliases.
The solution is attribute-level sync flags. Each attribute on a user record has metadata indicating which system is authoritative for that value. When a sync runs, the orchestrator checks the flag before deciding whether to push or pull.
This sounds complicated, but it matches how organizations actually work. The HR team manages HR data. The IT team manages technical access. The email admin manages distribution lists. Each team works in their preferred system, and the orchestrator keeps everything consistent.
Conflicts still happen. Someone updates a field in two systems before sync runs. The orchestrator needs rules for resolving these: timestamp wins, specific system wins, alert a human. The right choice depends on the attribute and the organization policies.
Scale Considerations
A few hundred users, you can brute-force this. Full sync every hour, compare everything, update what changed. A few thousand users and this starts to strain. Tens of thousands and it falls over completely.
A system built on these principles manages hundreds of thousands of user records. Full sync is not possible at that scale. Instead, changes are tracked incrementally. Each system reports what changed since the last sync. The orchestrator processes only the deltas.
This requires buy-in from the connected systems. the primary directory has change tracking built in (USN changed). Google has a sync API with delta support. M365 has delta queries. Not every system cooperates this well. Some require polling and comparison, which gets expensive.
The other scale problem is consistency. With hundreds of thousands of records, something is always in the process of syncing. A query might return stale data because the update has not propagated yet. The system needs to handle this gracefully, either by accepting eventual consistency or by implementing synchronous updates for critical operations.
The Security Model
An identity orchestrator is a high-value target. It has credentials for every connected system. A compromise means access to everything.
Defense in depth matters here. The orchestrator should not store credentials in plain text. It should not have more access than it needs. It should log every action for audit. It should require its own strong authentication.
The implementation uses credential storage using hardware security modules where possible, encrypted storage where not. Service accounts have minimal permissions, just enough to read and write user attributes. Every sync operation is logged with before and after states.
The dashboard itself requires multi-factor authentication. Role-based access controls limit who can see what. Bulk operations require approval workflows.
What Changes
Once the orchestrator is running, the operational model shifts. The help desk stops logging into multiple systems. They work in one place, and the orchestrator handles the rest.
User onboarding goes from hours to minutes. Create the user once, assign the right sync flags, and every system gets configured automatically. Offboarding is instant and complete.
Password reset calls drop because users have one password that works everywhere. Audit reports pull from a single source. Access reviews show a unified view of who has access to what.
The systems people used to complain about become invisible infrastructure. the primary directory, Google, M365: they are still there, still running, but nobody thinks about them individually anymore. They are just endpoints that the orchestrator manages.
The Broader Principle
Identity fragmentation is a symptom of a larger pattern. Organizations accumulate systems over time. Each system brings its own data model, its own management interface, its own operational burden. The complexity compounds until managing the systems is a full-time job for multiple people.
The fix is always the same: build an abstraction layer that unifies the complexity behind a single interface. Do not try to replace the systems. Do not try to force them to talk directly. Build something that translates between them and presents a coherent view to operators.
This works for identity. It works for device management. It works for configuration management. Any domain where data lives in multiple systems can benefit from an orchestration layer that makes those systems feel like one.
The investment is building the layer. The payoff is years of reduced operational friction.
