System Layer — Shared Services Behind HEPO
Understand HEPO's shared security, data, integration, local AI, workspace, and extension services, and how to evaluate them in your deployment.
Data Integration: connectors, mappings, and delivery
Configure external data connections, inspect transformations and delivery records, and distinguish intake from supported authorised writeback.
Configure external data connections, inspect transformations and delivery records, and distinguish intake from supported authorised writeback.
Data Integration is HEPO's shared capability for exchanging agreed information with external systems. Implementers configure connectors, field mappings, schedules, and delivery records so the organisation can identify what is exchanged and how it is handled.
This page describes the common integration layer. The Process data-integration page explains how a process uses that layer for evidence and authorised delivery. People & Culture and other modules can use relevant imported information under their own defined scope.
Four working parts
| Capability | What the implementer or operator examines |
|---|---|
| Connectors | The source or destination, connection configuration, credentials, and supported adapter behaviour |
| Mappings | How source fields and identifiers correspond to the intended HEPO records or outbound payload |
| Schedules | The configured cadence or supported trigger for an exchange |
| Delivery records | The available status and context of a run, including outcomes that need attention |
Authentication, pagination, rate limits, and trigger support depend on the adapter and external system. A connector framework supplies a common place for those concerns; it does not make every vendor system compatible without implementation work.
Follow a quotation's external information
A quotation process needs relevant information from an existing business system. The implementer agrees which records and fields may be read, how their identifiers resolve, and how fresh the information needs to be. A mapping gives the incoming values their intended representation.
The process then uses that information with its other inputs. When a value is surprising, the reviewer needs enough source and delivery context to investigate the record, mapping, and timing rather than treating the imported value as self-explanatory.
Intake and writeback are separate decisions
The ERP can remain the system of record for its domain while HEPO reads agreed information. Where a workflow also requires outbound delivery, that path needs a supported writable adapter and separate permission and ownership decisions.
An attempted send, a confirmed write, and a failed or retrying delivery are different outcomes. The receiving system's response and the process's completion rules must establish which one counts as completion. Configuring an input source does not implicitly authorise changing it.
This distinction preserves the alongside-ERP posture without claiming that all integration is permanently read-only or that every connector supports writes.
Examine failure as well as the happy path
Agree what happens when credentials expire, a mapping is invalid, a source record cannot be resolved, or a request is retried. Idempotence, duplicate handling, reconciliation, and recovery depend on the specific operation and adapter; they deserve their own demonstration.
Data owners decide authority and scope. Implementers build and verify the supported exchange. The delivery partner walks the organisation through the mappings and available delivery records, using representative data and both successful and failed runs.
Interoperability adds the tool-invocation perspective. Data Integrity covers validation and ownership after information crosses the configured boundary.
