One-Way vs Two-Way Integration: How to Choose Between Them

Most integration headaches do not come from technology choice. They come from the wrong direction of data flow. A team picks "real-time bidirectional sync" because it sounds modern, ships it, and spends the next two years debugging conflicts that would not exist with a simpler one-way design. Another team picks one-way to be safe, and ends up with users tabbing between two systems to copy the same record twice. Direction is the first design decision, the one that should be made deliberately for every data flow, and the one most projects skip past on the way to picking a vendor.

Why the direction question matters more than the technology choice

An integration project usually starts with the obvious question: "How will System A talk to System B?" That question, framed that way, jumps straight to mechanism: REST? webhooks? message queues? ETL? But the prior question is the consequential one: does System A need to know what changes in System B, or only the other way around?

This is the direction question. It sounds trivial. In practice it determines:

• Which system is the source of truth for each piece of data. Bidirectional flow without a clear source of truth is a guaranteed conflict generator.
• What happens when the two systems disagree. One-way has no conflict to resolve; two-way always does, and you have to design for it.
• How much engineering you sign up for. Two-way is roughly three times the work of one-way for most data flows, because conflict resolution, eventual consistency, and audit logging all become first-class problems.
• How easy the system is to debug at 11pm. One-way failures are typically obvious. Two-way failures often present as silent data drift that no one notices for weeks.

Getting direction right is so much more valuable than picking the "right" technology that it deserves a dedicated decision step before any tool selection happens.

One-way integration: what it is

One-way integration is data flowing from a source system to a target system in a single direction. The source system owns the data. The target system receives a copy. Changes in the target do not propagate back to the source.

Some characteristics that follow from that definition:

• The source is the unambiguous source of truth. If the source and target disagree on a value, the source wins, full stop. There is no merge logic.
• The target is read-only for the synced fields. Users of the target can read the synced fields, but they cannot edit them. If they try, the next sync overwrites their change.
• Failure modes are local. If the sync breaks, the target gets stale, but the source is unaffected. Recovery is "re-run the sync".
• The flow is one of either push (source notifies target) or pull (target fetches from source). Both are one-way in the architectural sense. The choice between push and pull is a separate question with its own tradeoffs.

The mental model: the target is a read-only mirror of a subset of the source's data, kept reasonably fresh.

Two-way integration: what it is

Two-way (or bidirectional) integration is data flowing in both directions between two systems. Either system can be the originator of a change, and that change has to propagate to the other.

Characteristics:

• No single source of truth for the synced fields. Both systems can write. The "source of truth" becomes a function of which system wrote last, or some more sophisticated conflict-resolution rule.
• Conflict handling is a first-class concern. What happens when the same record is edited in both systems at the same time? You need an answer designed in, not discovered at runtime.
• Eventual consistency is the norm. The two systems will be momentarily out of sync between when a change happens in one and when it lands in the other. The integration has to cope with operations performed on the briefly-stale data.
• Failure modes are global. A break in the sync can mean either system holds the truth for some records and the other holds it for others, and figuring out which is which is its own engineering problem.

The mental model: both systems are co-owners of the synced data, kept consistent by an integration layer that has to negotiate disagreements.

How one-way actually works in practice

A canonical one-way flow has four moving parts:

1. A change detection mechanism on the source. The source needs a way to know what has changed since the last sync. Common options: a timestamp column ("updated_at"), an event stream the source emits, a change-data-capture log, or a brute-force comparison of two snapshots.
2. A transport layer. The mechanism that moves the change from source to target. REST APIs, message queues, file drops, ETL jobs, webhook callbacks. The choice depends on latency requirements, volume, and operational maturity.
3. A target write path. The target needs to accept the change and apply it. Upserts are typical. Idempotency is required, the same change should be safe to apply twice without effect.
4. An audit log and reconciliation pass. An out-of-band check that compares source and target periodically to catch drift. Even one-way flows drift over time if change detection misses a change. The reconciliation is what catches that.

A real example: pushing the asset master from an EAM system to a finance/ERP system. EAM owns asset records. Finance reads them for depreciation and capex tracking. The EAM emits asset-changed events; an integration service consumes the events and upserts into the ERP's asset table. The ERP's asset records are read-only in the ERP UI. A nightly reconciliation script compares EAM and ERP asset counts and IDs, alerting on drift.

That pattern, written down, looks small. The reason one-way works well is precisely because it stays small. The temptation in any real project is to make it "just slightly more than one-way": allow finance to add a few finance-specific fields, sync those back to EAM, and suddenly you have an undeclared two-way integration with none of the design rigour two-way demands.

How two-way actually works in practice

A canonical two-way flow has the same four moving parts on each side, but with three additional layers that one-way does not need:

1. A change-origin tag on every change. When a change is propagated from A to B, B's write must be marked as "originated in A" so that B's own change-detection mechanism does not re-emit it back to A. Without this, you get infinite loops.
2. A conflict-detection mechanism. When both systems edit the same record between syncs, the integration needs to detect it. The usual tool is a version number or vector clock per record. The integration compares versions on arrival; a mismatch means a conflict to resolve.
3. A conflict-resolution rule. Once a conflict is detected, what wins? Last-write-wins is the simplest but loses data silently. Source-precedence ("changes from System A always beat changes from System B for this field") is explicit and audit-friendly. Manual review queue is the most rigorous but adds operational overhead. Most real systems mix these per field.

A real example: synchronising work orders between an EAM (operations creates and owns work orders) and an ERP (finance approves the costs and adds GL coding). Operations users edit the work order in the EAM. Finance edits cost-coding fields in the ERP. The integration syncs both directions.

The design rule that makes this tractable: partition the fields by owner. Operations fields (description, asset, technician, status) are write-only-from-EAM, read-only-in-ERP. Finance fields (GL code, project code, approval status) are write-only-from-ERP, read-only-in-EAM. Both systems hold the full record for visibility, but each field has exactly one writer. The "two-way" is at the record level; at the field level it remains one-way, which is what keeps it sane.

When teams skip this partition and let both systems write the same field, they sign up for the full eventual-consistency engineering challenge. That challenge is solvable but expensive. Far better to avoid it where the data model permits.

The decision framework

For each data flow between two systems, ask these questions in order:

1. Which system is the natural owner of this data? If the answer is unambiguous (one system clearly originates the data), default to one-way from owner to consumer.
2. Does the consuming system need to update this data? If no, you are done. One-way.
3. If yes, can the consuming system update different fields of the same record rather than the same fields? If yes, you have field-partitioned bidirectional flow. Each field stays one-way; the record is two-way. Easier than full two-way.
4. If both systems need to update the same fields, is there a deterministic precedence rule? (For example, "approvals from the ERP always win over operational edits in the EAM".) If yes, full two-way with a precedence rule.
5. If both systems need to update the same fields and there is no deterministic precedence, you are in true conflict territory and need either last-write-wins (and accept silent data loss) or a manual review queue (and accept operational overhead). Avoid this if you possibly can.

Going through this list per data flow, not per system pair, typically reveals that most flows in any real integration are one-way or field-partitioned. The true-two-way cases are rare, and naming them explicitly lets you put the engineering effort where it actually pays off.

When one-way is the right call

One-way is the right default for any of these patterns:

• Master data flowing from a system of record to consumers. Customer master from a CRM to an ERP. Asset master from an EAM to a finance system. Vendor master from a procurement system to a CAFM. The system of record owns the data; consumers read it.
• Reference data and configuration flowing from a central system to local copies. Chart of accounts. Cost code list. Currency master. Country list. All best maintained in one place and replicated outward.
• Analytics and reporting feeds. Data warehouse feeds, BI extracts, audit dumps. The reporting layer never writes back to the source; one-way is correct and obvious.
• Daily reference data from external sources. Exchange rates, interest rates, fuel prices, market data. The external publisher owns the data; your systems consume it. See the daily FX rate sync pillar for one worked example.
• Compliance and audit logging. Forward-only stream of events from operational systems to a compliance store. One-way by design and by regulation.

A reasonable rule: if you can't immediately articulate why this flow needs to be two-way, it does not need to be two-way.

When two-way earns its complexity

Two-way is genuinely the right design when:

• Two systems hold partially overlapping records and both have legitimate write authority. The classic case is the work-order example above: operations and finance both edit work orders, but on different fields. Field-partitioned two-way is the right answer.
• The user experience requires both systems to feel up-to-date. A field engineer using a mobile EAM client edits a work order; the back-office user in the ERP needs to see the change. The back-office user updates approval status; the engineer needs to see it on their mobile. Both ends need writes.
• Both systems serve different user populations who need authoritative interaction. Sales reps live in a CRM; finance lives in an ERP. Both need to interact with customer master records (rep updates contact info; finance updates credit terms). Field-partitioned two-way.
• The data is fundamentally co-owned by intent. Some inventory systems and warehouse-management systems genuinely co-own stock balances because they both need to react in real time to events. Same with order systems and fulfilment systems.

The bar is high deliberately. If a flow can be modelled as one-way with a manual fallback (a screen in the source system where the consumer can submit change requests that get processed by the source's owner), that is almost always cheaper than two-way, and the operational discipline it forces is often a feature rather than a cost.

The hybrid: most real systems are partially two-way

The honest answer for most enterprise integrations is that the system as a whole is bidirectional, but the individual data flows that compose it are mostly one-way, with a small number of explicitly two-way flows for the records where it is genuinely needed.

An EAM and an ERP integrated together typically has:

• Asset master: one-way EAM to ERP.
• Cost codes / chart of accounts: one-way ERP to EAM.
• Vendor master: one-way procurement system to both.
• Work orders: field-partitioned two-way (operations writes operations fields; finance writes finance fields).
• Purchase requisitions: typically one-way EAM to ERP, with an approval-status return path that is the only field flowing back. So mostly one-way, with one return-path field.
• Currency rates: one-way external source to both.

That breakdown is typical, not exotic. When integration architects talk about "integrating EAM and ERP", they are usually describing a portfolio of flows like this, not a single bidirectional pipe. Reasoning about each flow on its own merits, with the decision framework above, leads to a system that is mostly one-way (cheap to build, easy to operate) with the small number of genuinely two-way flows handled with the rigour they need.

Implementation patterns

Within each direction, there are several mechanisms. The choice depends on latency, volume, and operational maturity.

• Batch ETL / file drop. Run periodically (hourly, nightly), pull or push a batch of records. Simple, robust, well-understood. The latency cost is acceptable for most master-data flows. Operationally cheap.
• Direct REST API call. A change in the source triggers an immediate call to the target's API. Lowest latency, but the source must know about the target's API. Tight coupling. Failures of the target back-pressure on the source unless mitigated.
• Webhook callbacks. The source emits a webhook on change; a listener on the target side translates and applies. Decoupled from source code (the source doesn't know about the target). Latency low. Operationally needs a reliable listener with retry.
• Message queue. Source publishes change events to a queue; one or more consumers translate and apply to targets. Best operational maturity, durable, retryable, observable. Adds infrastructure complexity. Right call for high-volume, mission-critical flows.
• Event bus / pub-sub. Like a message queue but with multiple subscribers per topic. Right for flows where many consumers need the same change (an asset change going to ERP, BI, compliance, mobile app).
• Change-data-capture (CDC). The source database emits change records directly from its transaction log. Lowest impact on the source (no event-emission code needed), highest fidelity (you see every change including bulk updates). Operational and licensing complexity.

For a typical EAM and ERP integration on a mid-sized deployment, batch ETL covers the master-data flows; webhook or REST handles the work-order flows; CDC is only needed for the most performance-sensitive cases. Reaching for a message queue or event bus from day one is often over-engineering.

Conflict resolution strategies for two-way

For the genuinely-two-way flows, the conflict-resolution policy is the most important design decision. Five common strategies:

• Last-write-wins (LWW). Whichever system wrote most recently wins. Simple, automatic, requires no operational overhead. The cost: silent data loss when two near-simultaneous writes happen. Acceptable for low-stakes fields (a free-text "notes" field, perhaps). Dangerous for high-stakes fields (financial values, statuses).
• Source-precedence per field. A static rule: "for this field, changes originating in System A always win, regardless of timing." Explicit, audit-friendly, predictable. Requires the rules to be defined upfront and maintained as the data model evolves.
• Manual review queue. When a conflict is detected, the change is held in a queue and a human resolves it. Most rigorous, never silently loses data, but adds significant operational cost. Use sparingly for genuinely consequential fields.
• Merge by composition. For collection-valued fields (a list of tags, a set of attachments), merge the union of changes rather than choosing one. Works for additive changes; doesn't work for fields that need a single value.
• Field-level partitioning (the preferred answer). Avoid conflicts entirely by ensuring each field has exactly one writing system. The integration enforces this; UI in each system shows fields it doesn't own as read-only. This is what the work-order example above does.

The pattern that matters most: be explicit about which strategy applies to which fields, and write it down where the integration code can reference it. A conflict-resolution policy that exists only in the team's collective memory will quietly break with the first team turnover.

Real examples from CAFM, EAM, and ERP integrations

Four concrete scenarios, drawn from common enterprise integrations:

Example 1: Asset hierarchy and master data. The EAM (Hexagon EAM or IBM Maximo) is the authoritative source. New assets are commissioned in the EAM; their hierarchy, location, and criticality are maintained there. The ERP (Business Central, F&O) needs asset records for depreciation and capex tracking. Direction: one-way EAM to ERP. ERP users see asset records but cannot edit them; corrections go back to the EAM as a request. See asset hierarchy design for how to model this on the source side.

Example 2: Work-order processing. The EAM raises work orders; operations users update progress, status, and parts used. The ERP/finance side processes the cost coding, approvals, and the eventual GL impact. Both systems hold the work order. Direction: field-partitioned two-way. Operations fields write from EAM, finance fields write from ERP, both systems read the full record. See procurement workflow for the related flows on the procurement side.

Example 3: Purchase requisition to PO. A maintenance team raises a PR in the EAM. The PR is approved or rejected in the ERP. The approval status needs to flow back to the EAM so the requester sees their PR's state. Direction: one-way EAM to ERP for the requisition itself, with one return-path field (approval status) for the response. Mostly one-way with a single response field. Far simpler than full two-way.

Example 4: Exchange rates. The external publisher (a central bank) owns the data. The ERP and EAM both consume. Direction: one-way external to internal. Both consumers receive identical, normalised rates from a single integration layer. See the daily FX rate pillar.

Notice that four representative flows produce one example of true field-partitioned two-way (work orders) and three examples of one-way (or mostly-one-way). That ratio is typical. Two-way is rarer than projects intuit.

Common mistakes

Patterns to watch for, all genuinely common in real projects:

• "Real-time bidirectional" as a default ask. Often appears in RFPs and project briefs without analysis. Push back. Ask which fields actually need to flow in both directions. The answer is usually fewer than the brief implies.
• Allowing edit-anywhere without partitioning fields. Both systems can edit the same field, "and we'll just do last-write-wins". This is signing up for silent data loss. Either partition the field or accept the loss explicitly.
• Missing the change-origin tag. Two-way integration without origin tagging creates infinite loops the moment a change propagates back through both systems. This is one of the more humiliating production discoveries.
• Skipping reconciliation. Even well-designed one-way and two-way flows drift over time. Periodic reconciliation catches drift before it becomes a months-of-data problem. Always build the reconciliation; if you don't have time to build the reconciliation, you don't have time to build the integration.
• Treating "the integration" as a single thing. Integration projects are portfolios of data flows. Each one needs its own direction decision. Treating them as monolithic produces overengineered solutions for simple flows and underdesigned solutions for complex ones.
• Ignoring failure mode design. What happens when System A is down and the integration cannot reach it? Does the change in System B queue and retry? Does it fail and require manual intervention? Does it silently drop? Designing for failure modes is the part of integration engineering that distinguishes prototypes from production systems.

What to measure

Four metrics, applicable to both one-way and two-way:

• Sync lag. Time from a change happening in the source to it appearing in the target. The headline latency metric.
• Sync success rate. Proportion of attempted syncs that completed cleanly. Failures should be alerting; the success rate is what gets reviewed monthly.
• Reconciliation drift. The count of records where source and target disagree, found by the reconciliation pass. Should be near zero; non-zero is investigated.
• For two-way: conflict rate. Frequency of detected conflicts. If conflicts are rare, your field partitioning is right. If they are frequent, revisit the design.

The right question is not which one, it is which per data type

Integration projects often present the direction question as a system-level choice: are we doing one-way or two-way integration between System A and System B? Reframed at the data-flow level, the question dissolves into a series of smaller and more answerable ones. Which records does each system own? Which fields does each system need to write? Where do the changes need to propagate?

Answered flow by flow, most integrations turn out to be mostly one-way, with a small number of genuinely two-way flows handled deliberately. That portfolio is cheaper to build, easier to operate, and far easier to reason about when things go wrong. The architects who get this right are the ones who slow down to ask the direction question for each flow rather than answering it once for the whole project.

Related reading on the engineering side: CAFM and Business Central integration, CAFM data migration strategy, and common CAFM implementation mistakes, several of which are integration-direction failures in disguise.