A sync conflict is simply a disagreement between two sources of information about the same thing. Understanding it clearly makes everything else easier.

The plain definition

Okta keeps a profile for every person. That profile is filled in from one or more outside sources, such as Active Directory, another directory service, or a human resources system. Each source sends its own version of the facts. When two sources send different values for the same fact, or when a source sends something that does not fit what Okta already holds, you have a conflict. Something has to decide which value is kept.

Notice that a conflict is not always an error in the technical sense. Nothing crashes. No red warning appears. The system happily picks one value and moves on. The danger is exactly that quietness: a wrong choice made silently, thousands of times, can leave people with the wrong access or no access at all.

Why scale changes the game

• More sources. Each extra directory or feed multiplies the ways two stories can differ.
• More frequency. Imports run every hour or even more often, so a bad rule repeats itself many times a day.
• More people. A mistake that touches one percent of users is a nuisance at 200 people and a crisis at 50,000.
• More owners. Different teams own different sources and may change them without telling the identity team.
• Less visibility. Nobody can eyeball tens of thousands of profiles, so problems hide until someone complains.

A handful of words carry most of the meaning in this topic. Learn them once and the rest reads easily.

One more word deserves attention: stable identifier. This is a value that never changes for a person or an account even when everything else does. Names change at marriage, emails change at rebrands, and departments change monthly. A stable identifier, such as an employee number or a directory’s internal account identifier, is what lets a system keep recognizing the same person through all of that change. Almost every good conflict strategy leans on stable identifiers.

Conflicts have ordinary, human causes. Knowing the usual suspects tells you where to look first.

The common sources

• Multiple directories. Head office, acquired companies, regional teams, and old migrations each keep their own copy of a person.
• An HR system plus directories. HR knows job facts, directories know sign-in facts, and both sometimes try to describe the same thing.
• Manual edits. An administrator fixes a typo in one place and forgets the others.
• Scripts and tools. Old automation keeps writing values nobody remembers authorizing.
• Mergers and migrations. Accounts are copied between systems and briefly exist twice.
• Timing gaps. A change reaches one system hours before it reaches another.
• Data quality. Spelling variants, extra spaces, reused employee numbers, and shared mailboxes.
• Product behavior. Import settings, matching rules, and push options that interact in ways no one planned.

To resolve conflicts, you first need a picture of how data travels into Okta and back out.

The cast of characters

• Sources. Directories such as Active Directory or LDAP, and human resources systems. They hold the original facts.
• Connectors and agents. Small programs, usually installed inside your network, that read the source and talk to Okta over outbound connections.
• The Okta profile. The unified record that applications and policies actually use.
• Mappings. Rules that translate a source’s attribute names and formats into Okta’s profile fields and back.
• Applications and targets. Where Okta sends identity data onward, sometimes including back into a directory.

flowchart LR
    AD1["Directory A"] --> AG1["Agent A"]
    AD2["Directory B"] --> AG2["Agent B"]
    HR["HR system"] --> CON["HR connector"]
    AG1 --> IMP["Okta import engine"]
    AG2 --> IMP
    CON --> IMP
    IMP --> MAT["Matching"]
    MAT --> MAP["Mappings and source priority"]
    MAP --> PRO["Okta user profile"]
    PRO --> APP["Applications and policies"]
    PRO -->|"Push"| AD1
    

Read the picture left to right. Sources hand their records to Okta through agents or connectors. The import engine receives them, matching decides which Okta person each record belongs to, and mappings with source priority decide which values land in the profile. The finished profile is what applications and policies see. In some designs, Okta then pushes changes back out, which creates a second direction of traffic and a second place for conflicts to arise.

Every conflict is born during an import or a push. Here is what happens during an import, step by step, in plain language.

Full versus incremental

A full import is a complete photograph. It is slower, but it can notice people who disappeared. An incremental import is a list of recent edits. It is fast and gentle, but it only knows about changes it was told about. If an incremental feed misses a change, perhaps because a replication hiccup hid it, the difference stays hidden until a full import catches it. Healthy designs combine both: frequent incrementals for freshness, periodic fulls for truth.

stateDiagram-v2
    [*] --> Reading
    Reading --> Staged: "records received"
    Staged --> Matching
    Matching --> Mapping: "match found or new person"
    Matching --> NeedsReview: "ambiguous match"
    Mapping --> Applying
    Applying --> Logged
    NeedsReview --> Logged
    Logged --> [*]
    

The best way to feel a conflict is to follow a single fact, such as a job title, as it moves through the system.

Suppose Priya’s job title is “Sales Manager” everywhere. On Monday, HR promotes her and records “Finance Manager”. The HR connector delivers the new title to Okta within the hour. Okta updates the profile. Applications see the new title.

Now add a complication. The corporate directory still holds “Sales Manager” because a directory administrator updates titles only quarterly. At the next directory import, the old title arrives. Whether Okta overwrites the new title with the old one depends entirely on the rule you set. If the directory has equal or higher priority for titles, the promotion is silently reversed. Priya’s profile shows “Sales Manager” again, and a policy that grants Finance tools by title quietly removes her access.

sequenceDiagram
    participant HR as HR system
    participant OK as Okta profile
    participant DIR as Directory
    HR->>OK: "Title is Finance Manager"
    Note over OK: "Profile updated"
    DIR->>OK: "Title is Sales Manager"
    alt "Directory has higher priority"
        Note over OK: "Title reverted to Sales Manager"
    else "HR has higher priority"
        Note over OK: "Directory value ignored"
    end
    

The lesson is that conflict outcomes are decided by configuration, not by luck and not by which update arrived most recently. Good teams treat priority as a deliberate, documented decision, made attribute by attribute.

Conflicts fall into a few families. Naming the family tells you which tool to reach for.

flowchart TD
    C["Sync conflict"] --> K["Identity key"]
    C --> M["Matching"]
    C --> A["Attribute"]
    C --> G["Group"]
    C --> L["Lifecycle"]
    C --> P["Credential"]
    C --> T["Timing"]
    C --> W["Write-back"]
    

The most basic conflict is two different people wanting the same sign-in name.

Why collisions are inevitable

Names are not unique. In a company of fifty thousand, there are many people named John Smith, and short formats that use first initial and surname will collide constantly. Each directory may have solved this locally, with one adding a number to the second Smith and another adding a middle initial. When their users all flow into Okta, collisions appear that neither directory could have seen alone.

What goes wrong

• A second person with the same username is rejected, and their import fails or sits unfinished.
• Worse, a system may treat the second record as an update to the first, so one person’s details overwrite another’s.
• A new hire is given the name of a former employee, and inherits old access or old email.

How to prevent them

• Pick a username format that is unique by construction, such as including an employee number or the full email address of a unique mailbox.
• Audit all directories for overlapping names before the first big import, and fix them at the source.
• Never reuse an identifier after someone leaves, or reserve retired names for a long quiet period.
• Keep the stable account identifier as the real key, and treat the visible name as a label.

flowchart TD
    N["Incoming record: asmith"] --> E{"Name already in Okta?"}
    E -- "No" --> CR["Create new user"]
    E -- "Yes" --> S{"Same stable identifier?"}
    S -- "Yes" --> UP["Update existing user"]
    S -- "No" --> QU["Collision: hold for review"]
    

Matching decides whether two records are the same human being. It can fail in two opposite directions, and both hurt.

Two ways to be wrong

Of the two, the wrong merge is more dangerous, so a careful design leans toward missing a merge rather than making a false one. A duplicate can be cleaned up later at leisure. A false merge can expose data the moment it happens.

Choosing good matching keys

• Strong keys. Employee number, a government-independent unique person identifier from HR, or a verified corporate email.
• Weak keys. First name, last name, department, or phone number. These are fine as supporting evidence, never as the only basis.
• Combined rules. Match when a strong key agrees and a second attribute does not contradict it.
• Sample before switching on. Review the proposed matches for a few hundred people before allowing automatic linking.

quadrantChart
    title Matching risk by key strength
    x-axis Weak key --> Strong key
    y-axis Rare data --> Common data
    quadrant-1 Safe and useful
    quadrant-2 Needs a second check
    quadrant-3 Avoid
    quadrant-4 Safe but incomplete
    Employee number: [0.9, 0.8]
    Corporate email: [0.75, 0.7]
    Full name: [0.2, 0.9]
    Phone number: [0.3, 0.3]
    

When two sources provide the same attribute, something must choose. If nothing does, the value flips back and forth.

The flip-flop symptom

The classic sign is an attribute that changes at every import. The HR feed writes “Finance”, then the directory writes “Sales”, then HR writes “Finance” again, hour after hour. Each write looks legitimate to the system. Logs fill with updates. Downstream applications receive change notifications constantly, and rules based on the attribute turn on and off like a flickering light.

Common attribute conflict patterns

flowchart TD
    V["Incoming value"] --> B{"Is it blank?"}
    B -- "Yes, from weaker source" --> IG["Ignore it"]
    B -- "No" --> P{"Source has priority for this attribute?"}
    P -- "Yes" --> AP["Apply value"]
    P -- "No" --> SK["Skip and keep current"]
    

A worked illustration

Consider a mobile phone number. HR holds a company mobile number, the directory holds whatever the employee last typed into a self-service page, and a facilities system holds a desk phone. If all three write the same field with equal priority, the number changes every time a different import finishes first. A better design keeps three separate attributes: a work mobile owned by HR, a personal contact number owned by the employee, and a desk phone owned by facilities. Many attribute conflicts vanish once you notice that two sources were never describing the same fact, only facts with the same label. Before ranking sources, ask whether you are really looking at one attribute or several that have been squeezed under one name.

Another useful habit is to give every attribute a short written definition, such as “the number a manager should call in an emergency”. Definitions expose hidden disagreements long before data does, because two teams that both believe they own “phone” will quickly discover they mean different things.

The central tool for attribute conflicts is deciding, in advance, which source owns which fact.

The principle: one owner per attribute

The cleanest designs give every attribute exactly one owner. Business facts, such as title, department, manager, start date, and employment status, are usually owned by the HR system, because HR is where those facts legitimately change. Technical facts, such as the sign-in name, the directory identifier, and group membership for infrastructure access, are owned by the directory that issues them. Contact details can be owned by whichever system people actually update, often the directory or a self-service portal.

When one owner is not possible

Sometimes two sources must both contribute, such as a person who exists in two directories. Then use ranked priority: the first source wins when it has a value, the second fills in when it does not. Write the ranking down, share it with the owners of every source, and review it whenever a source is added or retired.

flowchart LR
    HRS["HR system"] -->|"Priority 1: business facts"| PRF["Okta profile"]
    DIRA["Main directory"] -->|"Priority 2: sign-in facts"| PRF
    DIRB["Acquired directory"] -->|"Priority 3: fills gaps only"| PRF
    

Groups look simple, but they carry more conflict potential than people do, because they combine names, members, and nesting.

The usual troubles

• Same name, different groups. Two directories each have “Engineers”. Imported together, they look like one group, or they collide.
• Nested groups. Groups inside groups may be flattened or ignored, changing who is really a member.
• Cross-domain members. A group in one domain holds people from another, and the importing agent cannot always see them.
• Two masters. Membership is edited both in the directory and in Okta, so changes cancel each other.
• Huge groups. Groups with tens of thousands of members take long to import and push, and partial failures become likely.

Resolution approaches

• Give imported groups a prefix that names the source, so the names can never collide.
• Decide for each group whether the directory or Okta is the master, and never both.
• Prefer rules-based groups in Okta for access that depends on attributes, and keep directory groups for infrastructure.
• Test nested and cross-domain behavior with sample groups before importing the real ones.
• Split enormous groups into smaller purposeful ones.

flowchart TD
    G1["Directory A: Engineers"] --> PA["Okta group: A-Engineers"]
    G2["Directory B: Engineers"] --> PB["Okta group: B-Engineers"]
    PA --> RULE["Rules combine members for access"]
    PB --> RULE
    

Few conflicts are as costly as disagreeing about whether someone still works here.

Typical disagreements

• HR marks someone as terminated, but their account in a second directory is still enabled.
• A directory account is disabled temporarily during leave, and Okta deactivates the person permanently.
• A person is rehired, and an old deactivated profile competes with a brand new one.
• An import runs with the wrong scope and proposes to deactivate thousands of people at once.

Principles that keep lifecycle safe

• Let HR own employment status whenever an HR system exists, and treat directory flags as secondary.
• Treat a missing record carefully. A person absent from one import may have moved, not left.
• Prefer suspension over deletion for the first period after an apparent departure.
• Cap bulk actions. Stop and ask when an import would deactivate more than a small percentage of people.
• Reconcile across all directories so no leaver stays enabled somewhere.

stateDiagram-v2
    [*] --> Active
    Active --> OnLeave: "leave recorded"
    OnLeave --> Active: "return"
    Active --> Suspended: "departure signal"
    Suspended --> Active: "rehire or mistake corrected"
    Suspended --> Deactivated: "grace period ends"
    Deactivated --> [*]
    

Passwords can be held, checked, or reset in more than one place. When they disagree, people simply cannot sign in.

Two basic models

• Delegated authentication. Okta passes the password to the directory, which says yes or no. The directory is the only authority, so there is nothing to disagree with.
• Password synchronization. Okta stores its own protected copy, updated whenever the directory password changes. Two copies exist, so mismatches are possible.

How credential conflicts appear

• A person resets their password in Okta but the directory still holds the old one.
• A directory password is changed by a help desk, and the sync to Okta is delayed.
• Policies differ: the directory demands twelve characters and the cloud accepts eight.
• An account is locked in one system while the other keeps allowing attempts.

Resolution

Choose one password authority per population, and make the other systems follow it. Align password rules between Okta and the directory. Send password resets to the authority, never around it. Where delegated authentication is used, remember that sign-in now depends on the directory being reachable, so resilience of that path matters.

sequenceDiagram
    participant U as User
    participant OK as Okta
    participant AG as Agent
    participant DC as Directory
    U->>OK: "Sign in with password"
    OK->>AG: "Verify this password"
    AG->>DC: "Check credentials"
    DC-->>AG: "Accepted"
    AG-->>OK: "Accepted"
    OK-->>U: "Signed in"
    

Even when every rule is right, changes can arrive in the wrong order. Time itself becomes a source of conflict.

Where timing hurts

• Replication delay. A change made in one domain controller has not yet reached the one the agent reads from.
• Import schedules. A directory import and an HR import run minutes apart, and the later one carries older data.
• Rehire before leaver. A rehire record arrives before the earlier termination has been processed.
• Move during import. A person is moved between organizational units while an import is reading, so they appear twice or not at all for one cycle.
• Clock differences. Servers disagree about the current time, so “latest change wins” picks the wrong change.

Defenses

• Keep clocks synchronized across all servers involved.
• Schedule imports so that the highest-priority source finishes last, or, better, use priority instead of arrival order.
• Read from a consistent, healthy directory controller close to the agent.
• Make updates safe to repeat, so a late arrival corrects itself on the next cycle.
• Prefer eventual convergence: design so that a wrong value fixes itself within a cycle rather than lingering.

sequenceDiagram
    participant HR as HR system
    participant OK as Okta
    participant DIR as Directory
    HR->>OK: "Rehire recorded at 09:00"
    DIR->>OK: "Account still disabled at 09:05"
    Note over OK: "Without priority, the older status wins"
    DIR->>OK: "Account enabled at 10:00"
    Note over OK: "Correct state at next cycle"
    

Time zones, daylight changes, and clock trust

Large organizations span time zones, and some systems record local time while others record universal time. A change stamped at nine in the morning in one region and eight in the evening elsewhere may be the same instant or a day apart. If any rule compares timestamps, such as latest change wins, make sure every source is converted to one standard time first. Daylight saving changes add a further trap, because an hour of the year occurs twice and another does not occur at all, so scheduled imports can run twice or be skipped on those nights.

The safest approach is to avoid relying on timestamps for important decisions. Use priority for ownership, use stable identifiers for identity, and use time only to decide when to look again. Where time is unavoidable, keep a single trusted clock source across servers and record offsets in every log.

Sync normally flows into Okta, but sometimes Okta pushes changes back to a directory. This creates a second direction, and with it the risk of loops.

Why write-back exists

Many organizations still run applications that read from the directory. If Okta manages groups or attributes centrally, those applications need the changes. So Okta writes to the directory, which then becomes both a source and a target of the same data.

The loop problem

Imagine an attribute that is imported from the directory and also pushed back. Okta changes the value, the directory stores it, the next import brings it back, Okta sees a “change” and pushes again, and so on. Best case, it wastes resources. Worst case, two slightly different transformations fight each other forever, and the value drifts or flips.

Rules that prevent loops

• Make each attribute flow in only one direction.
• Do not import an attribute that you also push, or mark one direction as authoritative.
• Use narrow write permissions so the push can only touch what it should.
• Keep privileged accounts and groups out of both import and push.
• Watch the audit logs for attributes that change repeatedly in short periods.

flowchart LR
    DIR["Directory"] -->|"Import"| OK["Okta"]
    OK -->|"Push"| DIR
    DIR -.->|"Loop risk if same attribute"| OK
    

You cannot resolve what you cannot see. Detection turns silent disagreements into visible, countable work.

Two detection styles

• Event-based. Watch each import and push for signs of trouble: records skipped, matches held for review, attributes changing repeatedly, users proposed for deactivation.
• Comparison-based. On a schedule, compare sources with Okta and with each other, and list the differences. This is reconciliation.

What to compare

flowchart TD
    S1["Export from source A"] --> CMP["Comparison job"]
    S2["Export from Okta"] --> CMP
    CMP --> D["List of differences"]
    D --> T{"Known and expected?"}
    T -- "Yes" --> OK["Record and ignore"]
    T -- "No" --> Q["Open a ticket with owner"]
    

Once a conflict is seen, a rule must decide. There are only a handful of basic strategies, and each suits different facts.

Matching strategy to fact

flowchart TD
    CF["Conflict detected"] --> R{"Clear owner for this fact?"}
    R -- "Yes" --> PR["Apply source priority"]
    R -- "No" --> I{"Risky if wrong?"}
    I -- "Yes" --> HU["Quarantine for review"]
    I -- "No" --> FG["Fill the gaps from ranked sources"]
    

The best conflict strategy lives on paper, agreed by the people who own each source, before the first import.

What the policy contains

• The list of all sources, with an owner and a contact for each.
• For every attribute, the owning source and the fallback order.
• The identity key and the matching rules, with examples of edge cases.
• Group ownership rules and naming prefixes.
• Lifecycle rules, including grace periods and bulk action limits.
• Who reviews quarantined items, how fast, and how decisions are recorded.
• How and when the policy itself may change.

flowchart LR
    OWN["Source owners agree"] --> POL["Written policy"]
    POL --> CFG["Okta configuration"]
    CFG --> MON["Monitoring and reports"]
    MON --> REV["Periodic review"]
    REV --> POL
    

When the number of identities grows, the mechanics of moving data become a conflict source of their own.

What changes at scale

• Imports take longer. A full import of a very large directory can run for a long time, and the next scheduled one may start before it ends.
• Rate limits matter. Okta and the directories both limit how fast requests are accepted. Heavy imports, pushes, and automation compete for the same budget.
• Partial failures are normal. Out of a million operations, a few will fail, and the system must carry on gracefully.
• Peaks occur. Start of year, reorganizations, and acquisitions send thousands of changes at once.

Techniques

• Scope imports tightly, so only people who need Okta are read.
• Prefer incremental imports for freshness and schedule full imports outside business peaks.
• Stagger directories so they do not all import at the same minute.
• Throttle automation that calls Okta, and make it back off politely when told to slow down.
• Batch changes in sensible sizes and avoid enormous one-shot jobs.
• Split enormous groups and reduce attributes that change constantly.

gantt
    title A staggered import day
    dateFormat HH:mm
    axisFormat %H:%M
    section Incremental
    Directory A :a1, 00:00, 10m
    Directory B :a2, 00:15, 10m
    HR feed :a3, 00:30, 10m
    section Full
    Directory A full :b1, 02:00, 60m
    Directory B full :b2, 03:30, 45m
    

Thinking in budgets

A helpful way to plan for scale is to treat capacity as a budget that several activities share. Imports spend some of it, pushes to applications spend some, administrators using the console spend some, and automation scripts spend some. When the budget runs out, requests are slowed or refused, and the activity that suffers is often the one you can least afford to delay, such as a new hire needing access on their first morning. List every consumer of capacity, estimate the busiest hour, and leave headroom for surprises. When a consumer is not urgent, schedule it away from the busiest hour. When it is urgent, protect it by reducing less important consumers.

Remember also that a change which seems tiny can multiply. Adding one attribute to the mapping of a directory with fifty thousand people means fifty thousand more values to compare and, if they differ, fifty thousand updates flowing onward to every connected application. Estimate the multiplier before you press the button.

Large organizations rarely have one directory. Each additional one multiplies the conflict surface.

Layout choices

• One Okta connection per directory or forest. Clear boundaries, separate settings, easier troubleshooting.
• At least two agents per connection. One agent failing should not stop the import, but two agents with different directory views can also create inconsistent reads, so keep them near healthy, well-replicated controllers.
• Regional placement. Place agents close to the directories they read, to cut delays and timeouts.

Cross-directory consistency

Every attribute mapping must be defined consistently across directories, or the same person will look different depending on which directory supplied the record. Create a shared mapping standard, and use the same naming, formats, and codes. Where directories differ in structure, translate to a common shape during import instead of at every consumer.

flowchart LR
    subgraph EU["Europe"]
      DE["Directory EU"] --> AE1["Agent 1"]
      DE --> AE2["Agent 2"]
    end
    subgraph US["Americas"]
      DU["Directory US"] --> AU1["Agent 1"]
      DU --> AU2["Agent 2"]
    end
    AE1 --> OK["Okta"]
    AE2 --> OK
    AU1 --> OK
    AU2 --> OK
    

At scale, failures are routine. The question is whether a failure leaves a mess or heals by itself.

Idempotent by design

An operation is idempotent when doing it twice has the same effect as doing it once. “Set the department to Finance” is idempotent. “Add one to the counter” is not. Sync should be built from idempotent steps, so that when an import is interrupted and run again, the people already updated stay the same and only the unfinished ones change.

Handling failure

• Retry with patience. Temporary failures such as timeouts should be retried after a growing delay, not hammered.
• Isolate bad records. One malformed person must not block ten thousand good ones.
• Report persistent failures. If the same record fails repeatedly, someone must see it and fix the data.
• Avoid half-finished states. Where a change has two parts, such as moving someone and updating their groups, check both parts afterward.
• Prefer convergence. The next cycle should repair anything the last cycle missed.

flowchart TD
    OP["Operation"] --> RES{"Succeeded?"}
    RES -- "Yes" --> DONE["Record success"]
    RES -- "Temporary failure" --> WAIT["Wait, then retry"]
    WAIT --> OP
    RES -- "Permanent failure" --> REP["Report record and continue"]
    

The goal of safety rails is simple: a bad rule should hurt a few people, not everyone.

flowchart LR
    IMP["Import result"] --> CHK{"Within limits?"}
    CHK -- "Yes" --> APL["Apply"]
    CHK -- "No" --> HLD["Hold in quarantine"]
    HLD --> HUM["Human review"]
    HUM --> APL
    HUM --> RJ["Reject and fix source"]
    

Sync conflicts are not only an operations problem. They can be used to gain access, or they can accidentally hand it out.

How conflicts become security problems

• Account takeover by matching. If an attacker can create a directory account with an email that matches a privileged person, a weak match rule could link it to that person’s profile.
• Reused identifiers. A new hire given a former employee’s identifier may inherit their access.
• Stale leavers. Accounts left enabled in forgotten directories are favorite targets.
• Attribute-based privilege. If a rule grants access by department, then anyone who can edit department in any source can change their own access.
• Overpowered sync accounts. A service account with too many rights can write anywhere if it is stolen.
• Hidden writers. Old scripts and tools that change profiles without anyone watching.

Protective habits

• Match on strong keys that ordinary people cannot choose themselves.
• Keep privileged and administrator accounts out of automatic matching and group push.
• Give sync service accounts only the rights they use, and monitor them closely.
• Limit who can edit attributes that drive access, in every source.
• Alert on changes to matching rules, mappings, priorities, and agent registration.
• Review hidden writers and retire or document every one.

flowchart TD
    ATT["Attacker edits a source attribute"] --> RULE{"Does a rule trust that attribute?"}
    RULE -- "Yes" --> ACC["Gains access through the rule"]
    RULE -- "No" --> BLK["No effect"]
    ACC --> DET["Detected by change alert"]
    

Monitoring is the early warning system for conflicts. The aim is to hear about trouble from a dashboard rather than from a frustrated executive.

What to watch

Good alerts versus noisy alerts

An alert is only useful if someone acts on it. Every alert should name what happened, why it matters, who owns it, and what to look at first. Alerts that fire daily and are always ignored teach the team to ignore all alerts. Start with a small number of alerts that matter, tune them until they are rare and meaningful, and then add more.

flowchart LR
    LOG["Import and audit logs"] --> RULES["Alert rules"]
    AGT["Agent health"] --> RULES
    REC["Reconciliation results"] --> RULES
    RULES --> PAGE["Page on-call for urgent"]
    RULES --> TKT["Ticket for routine"]
    RULES --> DASH["Dashboard for trends"]
    

Baselines and seasons

An alert threshold is only meaningful against a baseline. Collect a few weeks of normal numbers for imports: how many people are created, updated, and deactivated on an ordinary day, and how long runs take. Then express alerts relative to that baseline, for example when the number of proposed deactivations exceeds three times the recent average. Remember seasons: the first week of a new year, graduation months, and reorganization quarters all produce legitimate spikes. Mark these in your calendar so the team can tell an expected surge from a mistake, and so that alerts are tuned instead of silenced.

Finally, test the alerts. Occasionally create a harmless fake condition in a test setup and confirm that the right person is notified within the expected time. An alert that has never been seen to fire is an assumption, not a control.

When a report arrives, such as “my title keeps changing” or “I have two accounts”, a steady routine beats guesswork.

flowchart TD
    RP["User reports a problem"] --> FAM["Sort into a conflict family"]
    FAM --> CMP["Compare Okta profile with each source"]
    CMP --> HIS["Read audit history"]
    HIS --> POL{"Matches written policy?"}
    POL -- "No" --> CFG["Fix configuration"]
    POL -- "Yes" --> REV["Review the policy itself"]
    CFG --> SIB["Search for similar cases"]
    REV --> SIB
    

Technology alone does not resolve conflicts. People with clear roles do, and at scale the roles need to be written down.

Roles

Queues and response targets

Response goals are an agreement, not a law of nature. The right numbers depend on your size and risk appetite. What matters is that they exist, that the queue is visible, and that old items are noticed. A quarantine that nobody reads is the same as having no safety rail at all, because the held change blocks real people while it waits.

flowchart TD
    ITEM["Conflict item"] --> SEV{"Severity"}
    SEV -- "Urgent" --> ONC["On-call identity engineer"]
    SEV -- "High or normal" --> REVQ["Reviewer queue"]
    SEV -- "Low" --> BAT["Weekly batch"]
    ONC --> RES["Resolve and record decision"]
    REVQ --> RES
    BAT --> RES
    

Most severe conflicts are caused by changes: a new mapping, a new source, a new rule. Handling change well prevents most trouble.

Changes that deserve extra care

• Adding or removing an organizational unit from import scope.
• Changing matching rules or the username format.
• Changing source priority or attribute mappings.
• Turning on deactivation, write-back, or group push.
• Connecting a new directory or HR source.
• Changing the sync service account or its rights.

A test set that finds problems

A safe sequence

Describe the change and how to undo it. Test in a non-production setup with the test people above. Preview in production if the feature allows it. Pilot with a small group and compare results with expectations. Roll out in stages, watching the monitoring signals from the earlier chapter. Keep the previous settings recorded and the way back rehearsed.

flowchart LR
    DESC["Describe change and rollback"] --> TST["Test with test people"]
    TST --> PRE["Preview in production"]
    PRE --> PIL["Pilot small group"]
    PIL --> ROL["Staged rollout"]
    ROL --> OBS["Observe signals"]
    

No situation produces more conflicts than combining two companies or moving from one directory to another. The best defense is preparation.

Why the peak is so high

• Two complete populations arrive together, with overlapping names, emails, and employee numbers.
• Some people hold accounts on both sides, and some roles are duplicated.
• Naming conventions, group structures, and attribute formats all differ.
• Pressure to finish quickly tempts teams to skip tests.
• The people who understood the old systems may have left.

A calm approach

gantt
    title A merger integration outline
    dateFormat YYYY-MM-DD
    axisFormat %b
    section Preparation
    Inventory and overlap analysis :p1, 2026-01-05, 21d
    Source cleanup :p2, after p1, 21d
    section Integration
    Import with actions off :i1, after p2, 14d
    Match review and pilot :i2, after i1, 21d
    Enable lifecycle actions :i3, after i2, 14d
    section Retirement
    Read-only and reconcile :r1, after i3, 30d
    

People problems inside the technical problem

Integration projects often stumble on people more than on data. Two teams that used to compete may disagree about whose naming convention survives, whose directory is the master, and whose administrators keep their rights. Technical rules that quietly pick winners can feel like personal verdicts. Involve both sides in writing the ownership policy, explain the reasons behind each choice, and keep a record of exceptions. When a decision is based on evidence, such as a collision count or a data quality score, it is far easier to accept than one that seems to come from nowhere.

Plan also for the users. People whose usernames change need clear notice, a transition period if possible, and a place to ask questions. A well-run technical migration that surprises the users still feels like a failure to them.

A short list of failures accounts for most of the bad days. Knowing them in advance makes them far less frightening.

A recovery rhythm

• Stop the bleeding. Pause the import or push that is causing damage. A pause is cheap and reversible.
• Protect emergency access. Use a tightly controlled break-glass account that does not depend on the directory.
• Communicate early. Tell support teams and affected users what is happening and when to expect an update.
• Find the cause. Check recent changes first, since most incidents follow a change.
• Repair and verify. Fix the cause, restore affected people, and verify with real users.
• Learn. Write down the cause and add the alert or check that would have caught it sooner.

flowchart TD
    INC["Incident"] --> STOP["Pause the suspect import or push"]
    STOP --> ACC["Confirm emergency access works"]
    ACC --> COM["Communicate status"]
    COM --> CAU["Find recent change or cause"]
    CAU --> FIX["Repair and verify"]
    FIX --> LRN["Record lessons and add checks"]
    

These approaches have repeatedly proved themselves. Adapt them to your own situation.

flowchart TD
    SRC["Many sources"] --> OWN["One owner per attribute"]
    OWN --> KEY["Stable identifiers as keys"]
    KEY --> MAT["Cautious matching"]
    MAT --> RAIL["Caps and quarantine"]
    RAIL --> PROF["Clean Okta profile"]
    PROF --> REC["Scheduled reconciliation"]
    REC --> OWN
    

These habits look convenient and cause lasting trouble. Learn to recognize them early, especially in inherited setups.

Every choice gives something up. Naming the trade-offs makes decisions deliberate and defensible.

The main trade-offs

Best practices

• Draw every source, its owner, and its data flows before configuring anything.
• Write the conflict policy and get each source owner to agree to it.
• Audit overlaps in names, emails, and numbers across all sources first.
• Choose unique usernames and stable identifier keys.
• Rank sources per attribute and ignore blanks from non-owners.
• Prefix imported groups and decide group direction explicitly.
• Start with lifecycle actions off, preview, pilot, and roll out in stages.
• Cap bulk actions and keep a rehearsed kill switch.
• Monitor agents, import counts, review queues, and configuration changes.
• Reconcile all sources on a schedule and track the difference count.

Common mistakes

• Assuming imports from different directories will not collide.
• Treating a missing record as a leaver without a grace step.
• Forgetting that a moved account may look like a new one.
• Combining several risky changes in one window.
• Leaving the review queue unstaffed.
• Letting people who can edit access-driving attributes go unmonitored.
• Ignoring clocks and time zones across systems.

quadrantChart
    title Choosing a resolution strategy
    x-axis Low impact if wrong --> High impact if wrong
    y-axis Clear owner exists --> No clear owner
    quadrant-1 Human review
    quadrant-2 Gap filling with checks
    quadrant-3 Latest change or gap filling
    quadrant-4 Strict priority with caps
    Contact details: [0.2, 0.7]
    Self-service nickname: [0.1, 0.3]
    Job title: [0.6, 0.15]
    Employment status: [0.9, 0.1]
    Ambiguous person match: [0.9, 0.9]
    

This picture is a way of thinking, not a measurement. Low-impact facts with no clear owner can use flexible rules. High-impact facts with a clear owner should use strict priority with caps. High-impact facts with no clear owner deserve human attention, because that combination is where wrong guesses become incidents.

A conflict program improves only if you measure it. A few simple numbers tell you whether things are getting better or worse.

Measures worth tracking

The improvement loop

• Review monthly. Look at the measures and the top causes of conflicts. One chart of the biggest cause per month is often enough.
• Fix the sources. Many conflicts trace to bad data that source owners can clean permanently. Share the list with them.
• Update the policy. When a new kind of case appears twice, add a rule for it.
• Retire old rules. Remove mappings, scripts, and exceptions that no longer serve a purpose.
• Share what you learn. Publish short notes so support, security, and source owners see patterns.

flowchart LR
    MEA["Measure"] --> ANA["Find top causes"]
    ANA --> FIX["Fix sources and rules"]
    FIX --> POL["Update policy"]
    POL --> MEA
    

To bring everything together, here is an invented company and a complete conflict strategy. The company, numbers, and names are made up for teaching.

The company

Northwind Logistics is a fictional freight company with 42,000 employees and contractors. It has a main corporate directory, two acquired companies with their own directories, a regional directory for warehouse staff that has never been fully cleaned, and a cloud HR system. Five years of mergers left it with 3,100 people who have accounts in more than one directory, an unknown number of orphaned accounts, and a help desk that receives about 400 identity tickets a month, a quarter of which are “my details keep changing” or “I have two accounts”.

The strategy

flowchart LR
    HR["HR system"] -->|"Owns business facts"| OK["Okta profile"]
    D1["Corporate directory"] -->|"Sign-in facts"| OK
    D2["Acquired directory 1"] -->|"Sign-in facts, prefixed groups"| OK
    D3["Acquired directory 2"] -->|"Sign-in facts, prefixed groups"| OK
    D4["Warehouse directory"] -->|"Read mostly, cleaned first"| OK
    OK --> Q["Review queue and caps"]
    OK --> APP["Applications"]
    

How the first six months went

The overlap audit found 3,100 multi-directory people, of whom 140 had employee numbers that disagreed between directories because of typing errors. HR corrected them, and automatic linking then worked for nearly everyone. About 60 cases stayed in the review queue and were resolved by hand in two weeks. Source priority ended the flip-flopping of titles, and the count of attributes changing repeatedly fell from hundreds to a handful in the first month.

In month two, an administrator moved a warehouse organizational unit into a new container, and an import proposed to deactivate 1,900 people. The two percent cap held the run, an alert reached the on-call engineer within minutes, and the scope was corrected before any account was touched. In month four, reconciliation found 210 leavers still enabled in the warehouse directory, which was cleaned and added to the weekly report. By month six, identity tickets about conflicts had fallen from about one hundred a month to about twenty.

Short answers to questions that come up often. Okta features, limits, and menu names change over time, and some depend on your plan, so confirm exact details in the current Okta documentation.

Resolving directory sync conflicts at scale is mostly about clear ownership, careful identification, and safe change.