Relova — Remote Machine Connector
Connect an external database, spreadsheet or API and use its rows as live machines, parts and suppliers inside iTenance — without importing or copying the data.
Relova links iTenance to a system you already run — an ERP, a SCADA historian, a legacy asset register, a shared spreadsheet — and presents selected rows from it as normal iTenance records. The data is never copied into your tenant: every screen reads through to the source, so what you see is always current. Relova connections are read-only by design; Relova can never write back to the system you connect.
Relova or Mass Import?
Both bring outside data in. Choose by whether the source keeps changing.
Use Mass Import when…
- You have a one-off file (a supplier list, an opening asset register).
- You want the records to become fully editable iTenance data.
- The source will not change, or you are happy to re-import when it does.
Use Relova when…
- The source is a live system that updates on its own (ERP, historian, MES).
- You want machine readings or statuses reflected without a re-upload.
- You want a remote condition (temperature, run-hours, fault flag) to raise a work order automatically.
Before you start
- The Relova Remote Machines module must be active on your plan. Setup → Modules, or ask your account owner.
- You need the Manage settings permission — Relova lives under Settings.
- Have the source connection details ready: host, port, database name, and a read-only username and password. Create a dedicated read-only account on the source if you can.
- If the source only accepts connections from inside its own network, have SSH access to a host that can reach it (Relova can tunnel through it).
Step 1 — Open Relova
Go to Settings → Relova. The Overview tab shows four counters — Connections, Errors, Module mappings, Virtual references — and a list of your connections. The tab strip below the title (Overview · Connections · Mappings · Triggers) moves you between the screens.
Step 2 — Add a connection
Open the Connections tab and click New connection (top right, the “+” button). Fill in the form:
- Connection name — a label you will recognise, e.g. “Production ERP”.
- Database driver — MySQL / MariaDB, PostgreSQL, SQL Server, Oracle, SAP HANA, or a CSV / Excel file, or a REST API. The rest of the form changes to match.
- Host, Port, Database, Schema — network address of the source. Port pre-fills from the driver.
- Username / Password — the read-only credentials. They are encrypted before they are stored and are never shown again; leave the password blank when editing to keep the current one.
- Schema cache — how long (in seconds) Relova may reuse the list of tables and columns before re-reading it. 300 (5 minutes) is a good default; 0 disables caching.
- Query mode — Virtual reads through to the source on every view (freshest). Snapshot keeps a short-lived cached copy for faster lists. On demand only reads when someone opens the record.
SSH tunnel (optional)
Switch SSH tunnel on when the source is only reachable from inside a private network. Give the SSH host, port and user, and paste a private key (recommended) or a password. Leave the SSH host blank to tunnel through the database host itself.
CSV / Excel sources
For a file driver, give the absolute path to the file on the server and pick the delimiter. The file is read in place — put it somewhere your server can always reach, e.g. a synced folder.
Connection statuses
- Connected — last check succeeded.
- Degraded — reachable but slow or returning warnings.
- Error — the last check failed. Open the connection to see why; use Test connection after fixing.
- Disabled — you switched it off. Mapped records stop resolving until you re-enable it.
Each row has Test, Edit, Enable / Disable and Delete. Deleting a connection also removes its mappings and every virtual reference it produced.
Step 3 — Browse the source (optional but useful)
From a connection row choose Schema browser (the database icon). Pick the connection, and Relova lists its tables on the left. Click a table to see its columns — name, type, nullable, key — and click Preview data to see the first rows. Use this to find the exact table and column names you will need in Step 4. Refresh re-reads the schema and clears the cache.
Step 4 — Map a table onto a module
This is where remote rows become iTenance records. Open the Mappings tab and click New mapping.
- Connection and Source table — which remote table feeds this mapping.
- Mapping name — e.g. “ERP Assets”.
- Target module — Machines / Equipment, Parts, Inventory, Suppliers, Locations. This decides what the rows become.
- Premises — scope the mapping to one premises, or leave it open. A work order raised from this mapping is filed against this premises.
- Remote key column — the column that uniquely identifies each remote row (usually
id). Relova uses it to keep references stable between syncs.
Column mappings
Click Add mapping for each field you want filled: pick a local field (e.g. machine_name) and the remote column that feeds it. Fields marked * are required — the module will not accept a record until they are mapped. The panel tells you when every required field is covered.
Display fields
Tick the columns that should appear in the record’s snapshot — the values shown in lists and on the remote-record page. Keep this to what people actually need to see.
Static defaults & joins
Use default values to fill a required local column that has no sensible remote source — for example a fixed location_id, or a machine_id to anchor every row from this mapping to one iTenance machine. Use joins to pull a column in from a related remote table without a database view.
Sync behaviour
Virtual — always live. Snapshot cache — cache each row for the cache TTL you set (minutes). On demand — only read when opened. Add a change-detection column (e.g. updated_at) so Relova can fetch only rows that changed since the last sync instead of the whole table.
Living with remote records
- A remote machine looks like any other in lists and on its show page, with a small badge marking it as remote.
- Fields that come from the source (name, model, serial number, readings) are read-only in iTenance. Refresh from source on the record pulls the latest values.
- Local-only relationships — location, manufacturer, category, premises — are set with Edit relationships and stay in iTenance; a sync never overwrites them.
- You can raise work orders, add tasks and log downtime against a remote machine exactly as usual.
Step 5 — Raise work orders automatically (Triggers)
Open the Triggers tab and click New rule. A trigger watches one field of a mapping’s synced rows and opens a work order the moment the value meets your condition.
- Watch mapping — which mapping’s rows to watch (this also sets the premises the work order is filed against).
- Name — what this rule is for, e.g. “Bearing over-temperature”.
- When field — a column from the synced snapshot (start typing for suggestions from the mapping’s display fields), e.g.
temperature. - Operator — Rises above / Falls below / Equals / Greater than / Contains text / Is one of / Changes at all, and so on.
- Value — the number or text to compare against. “Is one of” takes a list; “Changes at all” needs no value.
- Priority — the priority the created work order gets (Low / Normal / High / Critical).
- Cooldown — minutes the rule stays quiet after it fires, so a value hovering around the threshold does not create a stack of duplicates. 1440 = one day.
- Title / Description templates — the wording of the work order. Drop remote values in with
{column_name}, e.g.Bearing alert: {temperature}°C on {machine_name}. Leave blank for a sensible default.
Security & isolation
- Read-only, always. Relova blocks any statement that is not a read. It cannot INSERT, UPDATE, DELETE or change the source schema.
- Credentials are encrypted at rest with a key that is separate from your other application data, and are never returned to the browser.
- Outbound requests are guarded. Relova refuses to connect to internal/loopback address ranges unless your operator has explicitly allow-listed a host, which stops a connection form being pointed at internal infrastructure.
- Every connection, mapping and remote reference is scoped to your tenant. One tenant can never see or query another tenant’s Relova data.
- Row limits and query timeouts apply to every pass-through read, so a bad mapping cannot pull an unbounded result set.
Troubleshooting
Test connection fails immediately.
Wrong host/port, or the source firewall does not allow your iTenance server. Confirm the details with a database client from the same network, then add the SSH tunnel if the source is private.
Connection tests fine but lists are empty.
The mapping has no required fields covered, or the source table name is wrong. Re-check Step 4 against the Schema browser, and use Preview.
“Required fields are not yet mapped”.
A NOT-NULL local column with no default is unmapped. Either map a remote column to it or give it a default value.
Values look stale.
The mapping is in Snapshot mode — lower the cache TTL, add a change-detection column, or switch it to Virtual. On a record, use Refresh from source.
Relova on the central domain shows nothing.
Relova always works from a tenant workspace. Open it from your normal tenant address, not the central sign-in domain.