The Business Engine keeps the same business record consistent across every connected system, in real time and in both directions. It is the real-time backbone the rest of the platform runs on: the pub/sub bus that Business Connectors and automations both publish to and subscribe from. This is what makes OneEnterprise fundamentally different.

What is it

A real-time synchronization engine built on a shared business language

The Business Engine is one of the two engines inside the OneEnterprise platform. Where the Automation Engine fires one-way trigger-action flows, the Business Engine does something harder: it keeps a single business record, a Customer, an Order, a Product, an Invoice, consistent across many systems at the same time.

It works through a publish and subscribe model. When a record changes in one system, the Business Engine translates it into a canonical OES object and publishes that change. Every other connected system subscribes and receives the same canonical update. No system talks directly to another, so adding a system does not multiply the number of point-to-point mappings.

Crucially, that bus is shared. Both Business Connectors and Automation Engine flows publish to and subscribe from it, so they work as one system rather than separate pipes.

Underneath it sits the OneEnterprise Specification (OES), a canonical set of business objects, and Business Connectors that encode the real rules of each system: localization, tax handling, transaction sequencing, and validation. The engine enforces data integrity before anything is written, so records never arrive out of order or half-formed.

At a Glance
TYPE
Real-time integration engine
MODEL
Bidirectional publish and subscribe
BUILT ON
OES canonical objects + Business Connectors
GUARANTEES
Prerequisite validation, identity resolution, no orphaned records
ROLE
Real-time backbone of the platform

Pub/sub architecture

Bidirectional, not trigger-action. A change in SAP publishes to OES, and every subscribed system receives the canonical update instantly.

OES canonical objects

Customer, Order, Product, Invoice, and many more. Business Connectors translate every record they handle through OES, into one shared canonical object.

Prerequisite check

Validates every object before it touches a target system. If an Order references a Product that has not synced yet, the record waits until the dependency resolves.

Patented Key Mapping

Cross-system identity resolution that works automatically. SAP “Customer 10042” and Shopify “cust_8xK2” resolve as the same entity, with no manual mapping tables.

Business Connectors

Not API wrappers. They encode real business logic: localization rules, tax handling, unit conversions, and transaction sequencing. OES lives inside every connector.

Park Queue

Records with unresolved dependencies are held, not dropped. The Park Queue releases them automatically when conditions are met, with full visibility into what is waiting and why.

One backbone, with OES at the center

OES canonical objects

Handled by Connectors + Automations

The governed, canonical cross-system lane. The star.

System objects

Handled by Automations

Objects a system passes or expects in its own native shape.

Custom messages

Handled by Automations

Your own message types, defined for a specific flow.

What it is for

Keeping shared business data true across every system

Most teams do not have a “data push” problem. They have a “same customer, three different versions” problem. The Business Engine exists to make one record the single source of truth and keep it accurate everywhere it lives.

Master data consistency

Customers, products, and vendors stay identical across ERP, e-commerce, and CRM. Update one, and every system reflects the canonical version in real time.

End-to-end transactions

Orders, deliveries, and invoices move through their full lifecycle across systems, with each step validated against the one before it.

Conflict resolution

When two systems change the same record, the engine resolves the conflict against canonical rules instead of silently overwriting one side.

Dependency-aware sync

The engine understands that an Order needs its Customer and Products first, and sequences writes so records never land orphaned or out of order.

This is “the 60%” of integration.

When to use it

Reach for the Business Engine when the same data has to stay true in more than one place

If you only need to fire an action when an event happens, the Automation Engine is the right tool. The moment the same record needs to live correctly in two or more systems, you need the Business Engine.

BUSINESS ENGINE
Use it when

  • A record must stay synchronized in both directions across systems

  • The same Customer, Product, or Order lives in your ERP, store, and CRM
  • You need conflict resolution, not last-write-wins overwrites
  • Writes have dependencies (an Order needs its Customer and Products first)
  • You need a canonical record that survives across system upgrades
  • Data integrity and a clean audit trail are non-negotiable
AUTOMATION ENGINE
Use that instead when
  • One event should trigger one or more downstream actions
  • You are pushing data one way, not keeping it in sync
  • You need notifications, alerts, or simple routing
  • A scheduled batch job moves data on a timer
  • No two systems need to agree on a shared record

These are not separate worlds. Automation flows and Business Connectors share the Business Engine’s pub/sub bus, so automations can react to canonical events and publish their own. In practice you use both together on one backbone. See the Automation Engine

What are the benefits

What you get that point-to-point integration cannot give you

DATA DRIFT

Zero

One canonical record, synchronized in real time, means systems never quietly disagree about the same customer, order, or price.

CONNECTIONS THAT SCALE

N, not N²

Every system connects to OES once, not to every other system. Adding a system is one connector, not a new web of point-to-point mappings.

ORPHANED RECORDS

No

Prerequisite validation and the Park Queue hold dependent records until they are safe to write. Nothing lands half-formed or out of order.

IDENTITY RESOLUTION

Automatic

Patented Key Mapping recognizes the same entity across systems without manual mapping tables to build and maintain.

BIDIRECTIONAL SYNC

Real-time

Changes propagate the moment they happen, in any direction, so every team works from current data instead of last night’s batch.

TRUST AND GOVERNANCE

Audit

Every translation and write runs through canonical rules with full visibility, giving finance and compliance teams a clean, traceable record.

This is the 60% that no other platform handles.

Trigger-action automation covers roughly 40% of what enterprises call “integration.” The remaining 60% needs bidirectional sync, data integrity guarantees, canonical objects, and real-time state management. That requires a fundamentally different architecture.

What automation alone cannot do
  • Bidirectional sync with conflict resolution
  • Prerequisite validation across objects
  • Cross-system identity resolution
  • Canonical data model enforcement
  • Real-time state management
  • Dependency-aware transaction sequencing
What the Business Engine was built for
  • Pub/sub architecture for instant, multi-system sync
  • OES canonical objects as the single source of truth
  • Patented Key Mapping for automatic identity resolution
  • Prerequisite Check to eliminate orphaned records
  • Park Queue for dependency-aware processing
  • Business Connectors with encoded domain logic

The Business Engine is one half of the architecture.
The OES specification is the language it speaks.

Canonical business objects, Business Connectors, and the pub/sub runtime work together as one system. Explore the specification that makes it possible, or see how both engines fit into the full platform.