Copying data in one direction is easy. Copying it in both directions invites arguments, and computers argue without ever noticing.

One-Way Is Calm

In a one-way flow, one system is the boss and the other follows. The human resources system says Dr. Mehta’s number is one thing, and the directory simply accepts it. If someone edits the follower, the next update from the boss overwrites the edit. Nobody has to decide anything, because the answer is built into the direction of the arrow.

Two-Way Is Busy

In a two-way flow, both sides can change data, and both sides send their changes to each other. That is useful. A person can fix their own phone number in a self-service application, and the fix reaches the directory. But it creates new questions. What if both sides changed the same field before either update arrived? What if the update from one side makes the other side send an update back, which makes the first side send another, forever? What if one side deleted the person and the other side just edited them?

Words like sync, import, and push are used loosely. Let us make them precise.

What It Is

Synchronization means keeping the same facts about the same thing consistent in two places. Bi-directional means changes can start on either side and travel to the other. In an Okta project, this usually means that some information about people flows into Okta from a source such as a human resources system, a directory, or an application, and some information flows out from Okta to those applications. When both directions carry the same kind of information, you have a two-way relationship, and you need rules.

What It Is Not

• It is not a database transaction. Two systems connected over the internet cannot change at the exact same instant. There is always a gap, and the gap is where conflicts live.
• It is not guaranteed to be instant. Imports can run on a schedule, pushes can be delayed, and queues can back up.
• It is not always field-for-field. Systems name and shape the same fact differently, and mappings translate between them.
• It is not automatic wisdom. The tools move data. They do not know which side is right unless you tell them.

Words Used in Okta Projects

A dozen terms carry most of the conversation. Each is explained with an example from Cedarwood.

Not all conflicts look alike. Naming them helps you pick the right remedy for each.

Real Conflicts and Fake Ones

Format mismatch and ordering problems are often mistaken for real conflicts. Fixing the mapping, such as storing phone numbers in one agreed format, removes a whole category of noise. Only once the noise is gone can you see the real conflicts: two people or two systems making different decisions.

Before settling conflicts, we need to know the parts Okta provides for bringing data in and pushing it out.

Exact feature names, which applications support which features, and the edition you need vary. Confirm the capabilities of your integrations in the integration’s own documentation. A connector that supports pushing profile changes may not support importing them, and the reverse is also common. That mismatch alone can produce one-way flows you did not intend.

The Two Roles of an Application

An application connected to Okta can play two roles at once. It can be a target, receiving accounts and updates from Okta. And it can be a source, supplying people and attributes into Okta. When an application plays both roles for the same attributes, you have created a two-way flow, whether you meant to or not.

flowchart LR
    HR["HR system: source"] -->|"import"| UD["Okta Universal Directory"]
    DIR["Directory: source"] -->|"import"| UD
    UD -->|"provision and push"| APP1["Application A: target"]
    UD -->|"provision and push"| APP2["Application B: target"]
    APP2 -->|"import: also a source"| UD
    

The single most effective conflict-prevention tool is deciding, attribute by attribute, who owns each fact.

The Idea of Mastering

Okta allows a profile source, such as a human resources system or a directory, to be the master of a user’s profile. When a source masters a profile, its values flow into Okta and overwrite local edits for the attributes it controls. Okta also supports scenarios with more than one source for the same user, where a priority order decides which source wins for each attribute. Details such as attribute-level control and how many sources are allowed depend on version and settings, so verify them in current documentation.

Ownership by Attribute, Not by System

Many teams try to pick one system as master of everything. That rarely fits real life. Human resources is the best source for legal name, job title, manager, and department. The person is the best source for a preferred nickname, a mobile number for alerts, and a profile photo. An application may be the best source for a license role it manages itself. Assigning ownership per attribute turns one big argument into a small table of calm decisions.

Let us name the parts that cooperate when a change travels through an Okta-based sync design.

flowchart TD
    HR["HR system"] --> C1["Connector in"]
    APP["Application with self-service edits"] --> C2["Connector in"]
    C1 --> MP["Mastering and priority rules"]
    C2 --> MP
    MP --> UD["Universal Directory: merged profile"]
    UD --> MAP["Outbound mappings"]
    MAP --> C3["Connector out"]
    C3 --> APP
    UD --> LOG["System Log"]
    LOG --> MON["Monitoring and alerts"]
    MON --> AUTO["Detection and repair flows"]
    AUTO --> UD
    

To resolve conflicts you must know how each direction really behaves, including its delays and quirks.

Import: Pulling Facts In

An import reads the user list and attributes from a source and compares them with what Okta already holds. Imports can be run on a schedule or started by hand, and some sources can also send change notifications. During an import, Okta must decide which incoming person matches which existing person, using matching rules such as username or email. People who match are updated, people who do not match may be created or held for review, and people who have disappeared from the source may be deactivated, depending on settings. Behavior varies by integration, so read the integration’s notes.

• Full versus incremental. A full import compares everything and can take a long time on large directories. An incremental import looks only at recent changes and is faster, but depends on the source reporting changes reliably.
• Matching. A loose match joins the wrong people. A strict match creates duplicates. Choose the field that is truly unique.
• Confirmation. Some setups hold new or unmatched users for an administrator to confirm. This is a gentle form of conflict handling.

Push: Sending Changes Out

When a profile changes in Okta, the platform can send the change to each assigned application. Each change becomes a request to the application, and the application answers success or failure. If the application is slow or unavailable, the request is retried or recorded as a failure that an administrator must handle. A push can also be triggered by someone changing the attribute mapping, which causes bulk updates for many users.

The Hidden Loop

If an application is both a push target and an import source for the same attribute, a push from Okta changes the application, and the next import reads that change back as if it were new. If the value is not byte-for-byte identical, such as a trailing space or a different capitalization added by the application, Okta sees a change, may push again, and the loop begins.

Follow Dr. Mehta’s phone number through a well-designed system, and then through a badly designed one.

sequenceDiagram
    participant P as Dr. Mehta
    participant A as Scheduling app
    participant O as Okta
    participant H as HR system
    P->>A: Updates mobile number
    A-->>O: Change detected at next import
    O->>O: Check owner of mobile number
    O->>O: Owner is the person, accept change
    O->>A: Confirm no push needed, value already matches
    H->>O: Sends HR record with old mobile number
    O->>O: HR is not owner of mobile number, ignore field
    O->>O: Log decision with both values
    

Stages of a Change

A Badly Designed Flow

In the poor version, nobody owns the phone number. The scheduling app’s edit is imported, then overwritten by the next human resources feed, which carries the old number. The person edits again, and again it is overwritten. Her edits seem to vanish. The cause is not a bug in any tool. It is an unanswered question about ownership.

Computer scientists have names for the different promises a system can make about agreement. Knowing three of them helps you choose the right promise for each attribute.

Choosing a Promise per Attribute

Because strong consistency is rarely available, the practical question is how long a gap you can tolerate, and what you do about it. For termination and sensitive groups, the gap must be minutes, so you use fast triggers and alerts. For phone numbers, a day is fine. Say so in the ownership table, next to each attribute, and then measure whether you meet it.

Time is the villain of most sync stories. Clocks disagree, messages arrive late, and the order of arrival may not match the order of events.

Why “Most Recent” Is Slippery

A rule like “the newest change wins” sounds fair, but newest by what clock? The clock of the application, of Okta, or of the person’s phone? Clocks drift by seconds or even minutes. Systems may record the time of the edit, or only the time the edit was noticed by an import, which can be hours later. A change made yesterday and detected today may look newer than a change made this morning and detected an hour ago.

Order of Arrival

Messages that leave in order can arrive out of order when retried or sent through different routes. If an update “title: Manager” is delayed and arrives after “title: Director,” the system may regress. Defenses include version numbers, change timestamps from the source system itself, and comparing the incoming value with the current one before overwriting.

Accepting Eventual Consistency

A mature design accepts that systems will briefly disagree, defines how long is acceptable, and sets alarms for when the gap is too long. This is called an eventual consistency window. For a phone number, hours may be fine. For a termination, minutes matter.

When a conflict needs special handling, you can often choose between three tools. Picking the lightest one that does the job keeps the system understandable.

A Simple Rule

Start with native settings. If they cannot express the rule, use automation for detection and small repairs. Reach for custom code only when the first two fail, and then keep the code small, tested, and documented. Every layer you add is another place where a conflict can hide, and another thing someone must understand when you move on.

When a real conflict happens, there are only a few honest ways to settle it. Each has strengths and costs.

A Ladder of Preference

Let us put the strategies to work on a real table of attributes.

When a new kind of disagreement appears, ask the same short list of questions in the same order. The answers point to the remedy.

flowchart TD
    Q1{"Did both sides change?"} -->|"No"| CATCH["Let the other side catch up"]
    Q1 -->|"Yes"| Q2{"Differ only in format?"}
    Q2 -->|"Yes"| NORM["Normalize and ignore"]
    Q2 -->|"No"| Q3{"Affects access or status?"}
    Q3 -->|"Yes"| OWN["Owner wins or human review"]
    Q3 -->|"No"| Q4{"Trusted timestamps?"}
    Q4 -->|"Yes"| LW["Last writer wins"]
    Q4 -->|"No"| OWN2["Owner wins"]
    

Loops are the most embarrassing kind of sync failure. They burn through rate limits, fill logs, and make values dance for days.

How a Loop Forms

flowchart LR
    O["Okta sets display name to Dr. A Mehta"] --> P["Push to application"]
    P --> AP["Application stores it as DR. A MEHTA"]
    AP --> I["Import reads DR. A MEHTA"]
    I --> D{"Different from Okta value?"}
    D -->|"Yes, by case"| O2["Okta updates to DR. A MEHTA"]
    O2 --> P
    

Ways to Break Loops

• One direction per attribute. If an attribute is pushed out, do not import it back, and the reverse. The simplest cure.
• Normalize before comparing. Trim spaces, fix case, and standardize formats such as phone numbers before deciding that two values differ.
• Compare before writing. Skip the write if the new value equals the current one after normalization.
• Mark the origin. If a change came from the sync itself, do not treat it as a human edit.
• Limit rates. Cap how often one attribute of one person may change per hour, and alert when the cap is hit.
• Watch logs for repeats. The same user and attribute appearing again and again in a short time is the signature of a loop.

You cannot resolve a conflict about a person until you agree which person it is.

The Matching Problem

When a new record arrives from a source, Okta must decide whether it describes someone it already knows. If the match key is the email address, then a person whose email changed after marriage looks like a stranger, and a duplicate is born. If the match key is a human resources employee number that never changes, matching is steady. Good keys are unique, stable, and present everywhere.

Typical Duplicate Problems

• Create versus create. The same contractor is created in two systems. When both import, two Okta users may result.
• Rehires. A person returns with a new employee number. Decide whether to reactivate the old identity or create a new one, and record the rule.
• Name changes. If the key is derived from the name, the person splits into two.
• Test and shared accounts. They collide with real people’s emails.

Linking Identities

Give every person a stable internal ID that all systems store, even if names and emails change. Keep a link table or an attribute holding each application’s own ID. When a new record arrives, match on the stable ID first. A confirmation step for ambiguous matches prevents silent mistakes.

The human resources system is usually the most trusted source of who works for the company. It also creates the trickiest timing conflicts.

Joiners

People are often entered in the human resources system weeks before their first day. If the feed creates the account immediately, a person may have access before they have joined. Many designs use the start date to decide when an account is created or activated. Conflicts arise when the start date is changed late, or when the person is created by another process first, for example a contractor-to-employee conversion.

Movers

When a person changes department or manager, several systems must follow. The manager change can reach Okta before the department change. For a short time the person has a new manager and an old department, which can trigger odd group rules. Design group rules to tolerate short partial states, or wait for both attributes to settle.

Leavers

Terminations may be future-dated, backdated, or reversed. A backdated termination tells Okta that someone left yesterday, and the system must act now. A reversed termination, when a leaver is rehired the same week, tries to reactivate an account that may already have been cleaned up. Each case needs a written rule.

Many companies keep a classic directory at the center of their world. When Okta joins it, a two-way relationship appears whether anyone planned it or not.

How the Pieces Relate

A directory such as Active Directory stores user accounts, group memberships, and passwords for a company network. Okta can connect to it through a lightweight program, often called an agent, that runs inside the company network. The agent imports users and groups into Okta and can also send certain changes back, such as password changes or group updates, depending on how you configure it. Which attributes go which way is set in mappings, and the options depend on version, so confirm in current documentation.

Where Conflicts Appear

• Attributes edited in both places. An administrator fixes a department in the directory tools while someone else fixes it in Okta. The next import or push overwrites one of them.
• Organizational units and filters. A user moved to a different container may fall outside the import scope, and Okta sees them as gone.
• Group membership. Group changes made directly in the directory may fight with Okta group rules that mirror the same groups.
• Passwords. If the directory owns passwords and Okta also lets users reset them, resets must flow back or be blocked, or the two systems will hold different passwords.
• Naming rules. The directory may require unique account names in a pattern, and Okta may generate a different pattern, leading to two identities for one person.

Removing a person is the most dangerous change in any sync. A wrong delete loses data. A missed delete leaves access open.

The Hard Cases

Safer Rules

• One owner of status. Only the human resources system, or a documented process, may change employment status.
• Deactivate, do not delete. Deactivation can be reversed and keeps history. Delete later, on a schedule, after a retention period.
• Safety brakes on mass changes. If an import would deactivate more than a set percentage of users, stop and ask a human.
• Tombstones. Record that a person was removed, so that a stale feed does not recreate them.
• Block reactivation from apps. Application-side activation should not change Okta status.

flowchart TD
    CH["Incoming change: deactivate user"] --> OWN{"From the status owner?"}
    OWN -->|"No"| IGN["Ignore and log"]
    OWN -->|"Yes"| MASS{"More than the safety limit at once?"}
    MASS -->|"Yes"| HOLD["Hold and alert human"]
    MASS -->|"No"| DEA["Deactivate in Okta"]
    DEA --> PUSH["Push deactivation to apps"]
    PUSH --> TOMB["Record tombstone"]
    

Many applications speak a common language called SCIM when Okta provisions accounts. Knowing a few details of that language explains many puzzling failures.

What SCIM Is

SCIM stands for System for Cross-domain Identity Management. It is a standard way for a service to accept requests such as “create this user,” “change this user’s title,” and “remove this user.” Using a standard means Okta can connect to many applications with the same pattern. Support varies between applications, so read each integration’s notes.

Details That Matter for Conflicts

Reading Errors Calmly

When a push fails, the System Log usually records the application’s reply. A “user already exists” reply suggests a duplicate that needs linking. A “not found” reply suggests the account was deleted on the application side. A “forbidden” reply suggests the connector’s permission has changed. Treat each as information about a disagreement between systems, and fix the cause instead of retrying forever.

Groups decide who can open which doors. A disagreement about membership is a disagreement about access, so it deserves extra care.

Where Group Conflicts Come From

Okta can push group membership to applications, and some applications can also import groups and members back. Trouble starts when both sides add or remove people. An application administrator adds a user to a local group, while an Okta rule removes the same user from the matching Okta group at the next evaluation. The two sides keep undoing each other.

Rules of Thumb

• One writer per group. Every group has exactly one system that may change its membership.
• Separate by name. Use naming that shows who owns the group, so nobody edits the wrong one.
• Treat unexpected app-side additions as findings. Detect them and either reverse or approve through a request process.
• Remove before add on moves. When a person changes department, remove old access first, so a failed step leaves them with less, not more.
• Reconcile regularly. Compare group membership in Okta with the application’s own list.

Many conflicts are born in the design of the attributes themselves. A clear schema removes whole categories of trouble.

Principles of Good Attributes

• One meaning per attribute. “Phone” that sometimes holds a desk line and sometimes a mobile number is a conflict waiting to happen. Create “work phone” and “mobile phone.”
• Consistent type and format. Store dates in one format, phone numbers with country codes, and country as a standard code.
• Clear empty value rules. Decide whether blank, missing, and “unknown” mean the same thing. A system that treats blank as “erase” will wipe values that another system treats as “no information.”
• Careful lists. Multi-valued attributes need rules for adding, removing, and ordering.
• Case and whitespace rules. Trim spaces and standardize capital letters for keys such as username.
• Documented owners. Every attribute has an owner, a purpose, and a retention note.

The Blank Value Trap

Suppose the human resources system has no value for a person’s cost center, while another system has one. If the feed sends an empty value and Okta treats it as an instruction, the good value is erased. A safer rule is that an empty value from a source is ignored unless the source is the declared owner and the field is explicitly allowed to be cleared.

Passwords are the touchiest data to sync. Two systems that both think they own a password create outages, lockouts, and security holes.

The Options

Why Two Masters Hurt

• Password rules differ, so a password valid in one system is refused by the other.
• A change that fails on one side leaves the user with different passwords in two places.
• Lockout counters differ, so a lockout in one system may not be mirrored.
• Sending passwords between systems widens the places a password could leak.

Even good designs let some differences slip through. Reconciliation is the regular health check that finds them.

What Reconciliation Does

Reconciliation compares what each system holds for the same people and lists the differences. For each difference it asks: who owns this attribute, which side is right, and what repair is safe? Simple, low-risk differences can be repaired automatically. Risky ones go to a person.

flowchart TD
    A["Export from Okta"] --> M["Match by stable ID and normalize"]
    B["Export from application"] --> M
    M --> C["Compare attributes"]
    C --> D{"Any difference?"}
    D -->|"No"| OK["Record clean result"]
    D -->|"Yes"| K{"Low risk and owner known?"}
    K -->|"Yes"| FIX["Auto repair toward owner value"]
    K -->|"No"| TICKET["Create review item for a person"]
    FIX --> LOG["Log repair"]
    TICKET --> LOG
    

Some conflicts should never be settled by a machine. A good queue makes human decisions quick and consistent.

What Belongs in the Queue

• Role or permission disagreements inside critical applications.
• Ambiguous matches that might join two different people.
• Mass changes that exceed the safety brake.
• Status disagreements involving leavers.
• Repeated conflicts on the same person, suggesting a deeper problem.

What Each Queue Item Should Show

Keeping the Queue Healthy

Assign an owner and a response time. Count how many items arrive each week, and treat the count as a measure of design quality. If the same kind of item keeps arriving, change the rules so it no longer needs a person. Every recurring item is a design bug, not a staffing problem.

When two companies merge, or one company runs several Okta orgs, the same person may exist in more than one place with different data.

The Merger Picture

After a merger, Company A and Company B each have their own identity systems and employees. Some people may have accounts in both, such as a consultant who worked for each. Others will be moved from one company to the other. For a time, both systems are live, and data flows between them to give staff access to shared tools.

Linking Orgs

Okta offers ways to connect one org to another, for example through an Okta-to-Okta integration that can provision users and groups and allow sign-in from one org into another. The details are product specific, so confirm current options. The design questions remain the same as for any two-way flow: which org owns which attributes, how are people matched, and what happens on deletion?

flowchart LR
    HRA["HR system, Company A"] --> OA["Okta org A"]
    HRB["HR system, Company B"] --> OB["Okta org B"]
    OA -->|"provision selected users and groups"| OB
    OB -->|"limited attributes back"| OA
    OA --> AA["Apps for A"]
    OB --> AB["Apps for B"]
    

Rules for Safe Linking

• Each person has one home org. The home org owns identity, status, and core attributes. The other org holds a guest copy.
• Limit what travels. Send only what the other side needs, such as name, email, and a few group memberships.
• Make the return flow tiny. If anything flows back, keep it to harmless attributes and never to status or access.
• Plan for the end. Decide when the two orgs will become one and how duplicates will be merged.

Networks fail, applications go down, and requests time out. A sync design must stay correct even when parts break.

Partial Failure

Suppose Okta updates a user’s title and pushes it to three applications. Two succeed and one fails. Now the user’s title differs across systems through no one’s decision. The system must remember that the third push is still owed and keep trying, without redoing the other two in a harmful way.

Idempotency Makes Retries Safe

If repeating an operation gives the same end state, retries are safe. “Set title to Director” is idempotent. “Add one day of leave” is not. Prefer designs that send the full desired value, not the difference, so that a repeated message does no harm.

A design that works for ten test users may struggle with ten thousand real ones, especially when many changes happen at once.

Where Scale Hurts

• Bulk mapping changes. Changing a mapping can trigger updates for every assigned user at once.
• Large imports. Full imports of big directories take long and may overlap with the next scheduled run.
• Rate limits. Okta and many applications limit how many requests they accept per time period. Exact limits vary by plan and endpoint, so check current documentation.
• Merger and reorganization waves. Thousands of title and manager changes arrive on the same day.
• Retry storms. When many requests fail, naive retries can pile up and make things worse.

Handling Bulk Work Safely

Whoever can change what flows between systems can change who has access. The sync is a privileged path and must be guarded as one.

Habits That Help

• Give each connector only the permissions it needs, and no more.
• Use separate service identities per integration, with named owners.
• Review who may edit mappings, profile sources, and automations.
• Treat data from outside systems as untrusted until the ownership rules approve it.
• Keep an independent copy of the logs.

If you cannot see the sync working, you cannot trust it. A few well-chosen measures reveal almost every problem early.

What to Record

Okta’s System Log records provisioning, import, and profile events, usually including the user, the application, the outcome, and an error reason when something fails. Event names and fields change, so inspect real events in your own org. Stream logs to a monitoring platform, because retention inside the product is limited.

flowchart LR
    SL["Okta System Log"] --> STR["Log streaming"]
    STR --> PLAT["Monitoring platform"]
    PLAT --> DASH["Dashboards: freshness, failures, conflicts"]
    PLAT --> ALR["Alerts: stale sync, loop signature, brake activated"]
    ALR --> ON["On-call identity engineer"]
    DASH --> REV["Weekly design review"]
    

When someone says “the data is wrong,” a steady routine finds the cause faster than guessing.

Every copy of a person’s data is another place to protect, explain, and eventually delete. Sync multiplies copies, so it multiplies duties.

What Auditors and Regulators Ask

• Where does each piece of personal data come from, and where does it go?
• Who can change it, and is that recorded?
• How quickly is a leaver’s access removed in every connected system?
• Are only the needed attributes shared with each application?
• How long is data kept, and how is it deleted everywhere?

Good Habits

Sync mistakes spread quickly and are tedious to undo. Testing before and during rollout keeps them small.

A Test Plan

Technology does not settle disagreements between departments. People do, and they need a clear structure to do it.

Meetings and Records

• A short weekly review of conflict counts, queue age, and sync freshness.
• A change calendar so that application upgrades and mapping edits do not surprise each other.
• A decision log capturing every ownership change with date, owner, and reason.
• A yearly review of the whole ownership table.

Two-way sync is not always worth its cost. Weigh the benefits against the complexity honestly.

Main Trade-offs

A few wrong beliefs cause most of the disappointment. Clearing them up early saves months of rework.

Habits that keep sync calm, and mistakes that keep recurring.

Patterns That Work

Anti-Patterns

Most failed sync projects do not fail on big ideas. They fail on small details that nobody wrote down.

A short list for design review and for yearly check-ups.

Design

• An ownership table exists for every attribute that crosses a system boundary.
• Each attribute flows in one direction wherever possible.
• Matching uses a stable unique ID, and ambiguous matches are held for review.
• Employment status and access groups have exactly one owner each.
• Formats are standardized and compared after normalization.

Safety

• Deactivate before delete, with retention and tombstones.
• Mass-change brakes are in place for deactivations and updates.
• Incomplete imports are treated as failures.
• Passwords are removed from applications where single sign-on is possible.
• Connector credentials are least-privilege, stored safely, and rotated.

Operations

• Each connection has an owner, a freshness target, and a stale-sync alert.
• Reconciliation runs on a schedule, with auto-repair for low-risk items.
• A conflict queue exists, with an owner and a response time.
• Bulk changes are previewed, piloted, staged, and followed by reconciliation.
• Logs stream to an independent platform with alerts for loops and brake activations.

Stories from the fictional Cedarwood Healthcare Group show the ideas at work. All numbers are illustrative.

Worked Numbers: Why Ownership Cuts Conflicts

Suppose Cedarwood has 7,000 staff and 12 attributes crossing system boundaries. If every attribute is two-way across three systems, then in a week with 2 percent of staff changing something, the number of potential collision points is large, and many need review.

The figures are invented to show a pattern: each design step removes a class of conflicts instead of settling them one by one. The cheapest conflict to resolve is the one the design never lets happen.

Few teams start with a perfect design. A short path shows how to improve steadily.

flowchart LR
    A["Inventory connections"] --> B["Draft ownership table"]
    B --> C["Fix loops and status ownership"]
    C --> D["Add brakes and normalization"]
    D --> E["Alerts and reconciliation"]
    E --> F["Weekly review and improvement"]
    

Let us put the ideas together by designing one complete two-way arrangement the way a working team would.

Step 1: List the Systems and the Directions

Cedarwood has a human resources system, a directory for its network, Okta, a scheduling application, a training application, and a clinical records application. The team draws every arrow and labels it import, push, or both. It discovers that the scheduling application is both a push target and an import source for phone numbers and display names, which no one intended.

Step 2: Write the Ownership Table

Step 3: Remove the Arrows That Should Not Exist

The team stops pushing display name to the scheduling application and stops importing the title from it. It turns off reactivation from the training application. It keeps the mobile number as a deliberate two-way attribute, with normalization.

Step 4: Add Protection and Eyes

Safety brakes are added for mass deactivation. A stale-sync alert is created for each connection. Reconciliation runs nightly on access-related data and weekly on the rest. A conflict queue is created and owned by the identity team.

flowchart TD
    A["List systems and arrows"] --> B["Write ownership table"]
    B --> C["Remove unintended arrows"]
    C --> D["Normalize formats and matching keys"]
    D --> E["Add brakes, alerts, reconciliation"]
    E --> F["Pilot, then widen"]
    F --> G["Review conflicts weekly"]
    

A quick reference for the words used in this guide.

Conflicts in two-way sync are not random bad luck. They are the predictable result of two systems with different clocks, formats, and opinions sharing the same fact without a rule. Good design gives them the rule.