Technology & integrations
The connective layer is the product. Everything else plugs into it.
Elion's advantage isn't a single application — it's that the applications talk to each other, and to the systems you already run. This page describes how that connection is actually made, and where it genuinely stops.
The connective layer
The solution areas
Data infrastructure
Connective layer
Integration patterns
Six ways two systems get connected.
Which one applies is decided per system during the mapping phase — not chosen in advance because it is the one we prefer to build.
Direct API integration
Where a system exposes a documented API, we connect to it directly — the cleanest and most reliable option, and the first one we look for.
Scheduled data exchange
Where live access is not available, records move on a schedule that matches how the business actually uses them.
Event-driven automation
Something happens in one system, conditions are checked, and the right action follows in another — instead of someone remembering to do it.
Read-only reporting links
Where a system must not be written to, we read from it for reporting and leave it entirely untouched.
Purpose-built connectors
Where nothing off-the-shelf bridges two systems, the connector itself becomes a small, scoped build.
Human-in-the-loop handoffs
Where an action carries real consequence, the system prepares it and a person approves it. That is a design decision, not a limitation.
We do not publish a logo wall of named integration partners. We connect to whatever your operation genuinely runs, and we name a specific vendor only where we have actually built and run that connection.
What the shared layer provides
The four things every Elion system inherits.
These are properties of the architecture, not features bought separately. A system built on it gets all four whether it is Commerce, Operations, Workspace or a custom build.
One operational record
Orders, stock, people and approvals live in one place and are referenced from everywhere else, rather than copied between systems.
Roles, branches and permissions
Who can see and do what is defined per role, per branch and per responsibility — decided during design, not patched on later.
A reviewable trail
Actions and approvals leave a record that can be reviewed afterwards, which is what makes a multi-stage approval chain meaningful.
Controlled releases
Changes are tested and rolled out in a controlled, monitored way rather than pushed live and watched.
In the products
Integration and automation, as they actually appear.
Delivery documents read by AI and then confirmed by a person; automation rules that connect the ERP to the people who act on it. Each capture carries its own status and disclosure.
Delivery documents read by AI, then reviewed by a person before anything is applied to stock.
Real production data, captured in the idle state — no document was uploaded during capture.
Rules that connect the ERP to the people who act on it: when something happens, if conditions match, then act.
Local demonstration with seeded accounts. Every automation shown is labelled DORMANT in the product — these rules are defined, not running in production.
Where AI is used
AI does the reading. A person still does the deciding.
AI appears in Elion systems where it removes genuine manual effort — and every one of those places keeps a review step, because that is what makes it safe to rely on.
What it does today
- Reading a delivery document and extracting its contents for a person to review before anything is applied to stock.
- Comparing expected against actual usage so an unexplained gap surfaces daily rather than at the next stock count.
- Routing and summarising work between departments so a request arrives where it belongs, complete.
The boundaries we hold
- AI output is reviewed by a person before it changes an operational record — extraction is a draft, not an entry.
- Accuracy depends on the document, the image, the lighting and the real operating conditions, and we say so rather than quoting a headline accuracy figure.
- Camera and sensor work supports human decisions; it does not replace them, and it is not facial recognition.
- Where a model is wrong, the design has to make that visible and correctable — that is part of the specification.
Camera and sensor work is described in full on Elion Vision, including what it deliberately is not.
The honest limits
What an integration cannot do.
Every one of these has changed a project's scope at some point. They belong on this page rather than in a conversation three weeks into an engagement.
- An integration can only expose what the other system actually makes available — a closed system stays closed.
- A vendor can change or withdraw an API, and a connector has to be maintained as a living part of the system.
- Two systems with genuinely different definitions of the same record need that conflict resolved by a decision, not by code.
- Real-time is not always the right answer; where a nightly exchange fits the business rhythm, that is what we build.
The next step
Start with a Systems Assessment.
A focused conversation about how your operation runs today, where it loses time, and what a connected system would change. No obligation to build anything.
In an assessment we
- Understand how your operation runs today
- Identify the disconnected systems and bottlenecks
- Map the highest-value improvements
- Decide together whether Elion is the right fit