Skip to main content

For data engineers and OT/IT leads · no form, no gate

How WorkSync connects: architecture and data flow.

You should not have to sit through a sales call to find out how a vendor touches your SCADA. This page is the technical walkthrough we give evaluation teams: what we read and over which protocols, how data moves and reconciles, what write-back actually means, and where the platform can run. Everything here is self-serve. The NDA-gated depth (SOC 2 Type I report, pen-test summary, threat model) is one request away on /security.

read-first by default/write-back opt-in per system/single-tenant · VPC · on-prem/no rip-and-replace

01 · The integration model

Read-first. Everything else follows from that.

WorkSync pulls from your systems of record without changing them. Four kinds of data come in: records (wells, work orders, tickets), time-series (tags, rates, pressures), documents (P&IDs, datasheets, as-builts), and geometry (GIS layers, routes). The pattern below is enforced on every connector, not negotiated per project.

Step 01

Read from systems of record

Pre-built connectors pull from Enverus, Quorum, Maximo, SAP, AVEVA PI System, AVEVA, Cygnet and 30+ more. Read-only by default. Your data stays your data; your stack stays your stack.

Step 02

Unify into the semantic model

Records, time-series, documents, and geometry land in one canonical asset model. Entity resolution, unit normalization, and quality flags run continuously. Nothing duplicated. Nothing lost.

Step 03

Serve to products. Write back with permission.

WellOPS, FlowSync, and Willie / Taylor read from the unified model. Write-back to source systems is opt-in per system and per target. Closed work orders flow back to Maximo only when you say so.

The protocols and standards we speak natively

Real-time & field data

OPC-UAMQTTREST APIModbus TCP/RTUDNP3KafkaAMQPIEC 61850

Enterprise & industry standards

ODBC/JDBCODataWITSMLPRODMLOSDUPPDMgRPC

Pre-built connectors, by category

Production & FOM

Enverus, Quorum, Enertia

EAM / Work Order

Maximo, SAP PM, IFS, Oracle EAM

SCADA & Historian

AVEVA PI System, Cygnet, Ignition, AVEVA System Platform / InTouch

Engineering

AVEVA, Siemens, AutoCAD, Bentley OpenPlant

Documents

SharePoint, OpenText, Hexagon SDx

Compliance & HSE

Intelex, Sphera, Enablon

GIS

Esri, FME

Not in the catalog? If a system exposes REST, SOAP, ODBC, or a scheduled export, our integration team connects it. Full catalog →

02 · How data moves

Polling, streaming, and an honest word about freshness.

Different sources move differently, and pretending otherwise is how integration projects earn their reputation. Here is the actual posture per source class.

SCADA & historians

OPC-UA or MQTT subscription, or the historian’s native API (AVEVA PI System, Cygnet, Ignition)

Streaming or short-interval polling. Time-series lands near-real-time, at the cadence your historian already publishes. We do not resample your tags into something faster than the source.

Production accounting, ERP, EAM

ODBC/JDBC, OData, or vendor REST APIs (Enverus, Quorum, Maximo, SAP)

Scheduled pulls, typically several times a day, set with your IT team. Transactional systems change on transactional cadence; polling them harder does not make the data fresher.

Documents, GIS, engineering files

REST APIs and file connectors (SharePoint, Esri, FME, CAD/P&ID parsers)

Event-driven where the source supports webhooks, scheduled sweeps where it does not. Parsed content is versioned so a re-issued drawing never silently overwrites lineage.

The freshness rule

We will not quote you a blanket latency number on a marketing page, because the honest answer is: freshness is a property of the source. Time-series arrives near-real-time from your historian’s cadence. Transactional data arrives on the schedule your systems actually change on. During integration we agree the cadence per source with your IT team, and the platform surfaces data age on every value, so a stale number looks stale instead of confident.

03 · Reconciliation

One well, three systems, one record: the API10/UWI walk.

The hard part of integration was never the pipe. It is making a decade of vendor data agree. One production system flags oil with a run code of 3, another with 1, and the same well answers to a UWI, an API10, and whatever the pumper has always called it. We encode those rules once, so every number downstream means the same thing.

Reconciliation · one rule set, every source

Raw · what your systems send

  • vendor A · OilWaterRunFlag = 3
  • vendor B · RUN_TYPE = "1"
  • scada · PRD_OIL_RT (bbl/d)
  • well keys · UWI, API10, pumper alias

One model · what everything downstream reads

  • oil_bbl · normalized from every run code
  • oil_rate · bbl/d, units reconciled
  • well · one identity, matched on API10
  • lineage · source tagged on every value

Entity resolution

UWI, API10, and field aliases resolve to one well identity. Facilities, meters, and routes get the same treatment. Ambiguous matches are queued for a human, not guessed.

Normalization & quality flags

Units, run codes, and timestamps normalize continuously. Values that fail range or consistency checks carry a quality flag downstream instead of being silently dropped or silently trusted.

Lineage on every value

Every number in the unified model is tagged with its source system and retrieval time. When accounting asks why a volume changed, the answer is a click, not an investigation.

04 · Write-back

Opt-in, per system, per target. Never to control systems.

What write-back is

Business-system updates you explicitly turn on: closed work orders flowing back to Maximo, completed field tickets posting to the system of record. Each write target is enabled individually, scoped to specific record types, approved by a human where you want one in the loop, and logged in a full audit trail.

What write-back is not

It is never OT. WorkSync does not write setpoints, does not touch PLC logic, and has no pushbutton-equivalent path to field equipment. SCADA integration is unidirectional by architecture. If nobody enables a write target, the platform stays read-only forever, and that is a fully supported way to run it.

05 · Where it runs

Three topologies. Your security team picks.

Single-tenant cloud

Dedicated tenant on AWS or Azure in a region you choose (US-East, US-West, EU). Customer-managed KMS keys (BYOK/HYOK) for data at rest, TLS 1.3 in transit. No shared infrastructure with other customers.

Fit: most operators. Fastest stand-up.

Your VPC

The agent and inference layer deploys into your own cloud tenant, including LLM inference on open-source models you host. Your data and your model calls never leave your environment.

Fit: teams with an established cloud footprint and strict egress rules.

On-prem edge

An on-prem edge connector runs the integration and agent layer entirely inside your network, with egress limited to the web UI and customer-initiated sync. Zone-and-conduit segmentation between IT and OT, allowlisted endpoints, IEC 62443-3-3-aligned controls.

Fit: air-gap requirements. The default pattern for the strictest OT environments.

Compliance posture across all three: SOC 2 Type II in progress, report targeted Oct 30, 2026, with the Type I report available under NDA today. IEC 62443-3-3-aligned OT controls, annual third-party penetration testing, SSO via SAML/OIDC, RBAC, and audit logs on every access. The full control list lives on /security.

06 · The negative space

What WorkSync does not do.

Half of a technical evaluation is ruling things out. Save yourself the discovery calls.

No rip-and-replace

Your SCADA, ERP, CMMS, accounting, and GIS stay exactly where they are. WorkSync reads from them; it does not migrate, replatform, or sunset them.

No data-lake prerequisite

You do not need a lakehouse, a UNS, or a finished master-data project first. The connectors and the reconciliation layer are the product. If you already run Fabric, Databricks, or Snowflake, we connect to it; if you do not, nothing is blocked.

No control-system writes

WorkSync cannot write setpoints, modify PLC logic, or issue pushbutton-equivalent commands. The OT boundary is enforced in the integration layer, not by policy.

No cross-tenant model training

Single-tenant architecture. Your operational data never trains a model another customer sees. Default LLM inference is open-source models in a dedicated US-region pool or your own tenant, with no third-party API calls unless you explicitly enable them.

Go deeper

Walk our architecture with your data lead.

Bring your data engineer or OT lead and we will walk this page against your actual stack: your historian, your accounting system, your network boundaries. A working session, not a pitch. And if you would rather keep reading first, everything below is ungated too.