Core concepts

What is INTERA? #

INTERA is a role-based operational visibility layer that connects to existing business systems and turns their data into structured, role-specific dashboards, indicators, and signals.

INTERA is not intended to replace billing systems, CRMs, ERPs, accounting platforms, ticketing systems, or operational software. Instead, it sits above them as a non-intrusive layer. It reads selected data from external systems, organizes that data into business objects, and presents it in a way that helps managers, operators, and executives understand what is happening without manually requesting reports from different departments.

For third-party developers, INTERA provides an integration framework. This framework allows external systems to expose data to INTERA through Integration Modules, DataSources, asset synchronization, and mapping rules. The purpose of an integration is not simply to transfer raw data, but to make external system data usable inside INTERA roles, dashboards, metrics, and business rules.

What is an Integration Module? #

An Integration Module is a packaged connector between INTERA and an external system.

It describes how INTERA can connect to that system, what configuration is required, what data can be requested, and which business entities or datasets the external system can provide. An Integration Module may connect to a modern API, a read-only API, a SQL database, a file export, a legacy system, or another structured data source.

A typical Integration Module includes:

• integration metadata, such as name, version, type, and capabilities;
• configuration fields, such as API URL, credentials, tenant ID, database connection, or file location;
• one or more DataSources for on-demand data access;
• optional entity providers for synchronizing external entities into INTERA;
• error handling logic;
• documentation and examples.

From INTERA’s point of view, an Integration Module is the technical contract that makes an external system understandable and usable. From a developer’s point of view, it is the unit of work that must be built, tested, versioned, and submitted.

An Integration Module should not expose unnecessary internal complexity of the external system. It should provide a clean, predictable interface that INTERA can use safely and repeatedly.

What is a DataSource? #

A DataSource is a named data endpoint exposed by an Integration Module.

It allows INTERA to request a specific dataset from an external system. For example, a billing system integration may expose DataSources such as customers, invoices, payments, services, or usage_records. A shipmanagement integration may expose vessels, certificates, work_orders, crew_assignments, or fuel_consumption.

DataSources are used when INTERA needs live or on-demand data. A dashboard widget, metric calculation, reconciliation rule, or role package may request data from a DataSource using parameters such as date range, asset ID, customer ID, product type, status, or limit.

A DataSource should return structured, predictable data. It should not return unfiltered system dumps unless that is explicitly required. The developer should design each DataSource around a clear business use case.

For example:

DataSource: invoices
Purpose: Return invoices from the external billing or accounting system.
Common filters:
- from date
- to date
- customer ID
- invoice status
- currency

DataSources are one of the most important parts of an INTERA integration because they define what information the external system can make available to dashboards, metrics, and role packages.

What is a Metric? #

A Metric is a measurable business value used by INTERA to describe the state, performance, risk, or activity of an Asset, role, department, or process.

Examples of Metrics include:

monthly_revenue
open_tickets
overdue_invoices
active_services
failed_activations
customer_balance
vessel_fuel_consumption
certificate_expiry_days

A Metric can be a number, currency amount, date, percentage, boolean flag, status, coordinate, text value, or another supported data type. Metrics may come directly from an Integration Module, may be calculated from one or more DataSources, or may be entered manually by users where appropriate.

In INTERA, Metrics are not just raw values. They can include context such as:

• the Asset they belong to;
• the time period they describe;
• the external DataSource that supplied them;
• their latest update timestamp;
• their status, such as valid, delayed, missing, or error;
• threshold ranges;
• trend information;
• role-specific display names.

For example, a telecom role package may display a Metric as “Monthly Revenue”, while a finance role package may display the same underlying value as “Recognized Revenue”. The Metric remains the same technical object, but its presentation can be adapted for the role and dashboard where it is used.

Metrics are the main building blocks for dashboards, health scores, reconciliation checks, pattern detection, alerts, and operational visibility.

What is Asset Mapping? #

Asset Mapping is the process of linking external objects from integrated systems to INTERA Assets.

An Asset is a business object that INTERA tracks locally. Examples of Assets include customers, vessels, products, suppliers, contracts, trucks, employees, sites, or services. External systems often contain similar objects, but each system may use its own identifiers, names, structures, and terminology.

For example, the same customer may appear in several systems:

Billing system: customer_id = 10482
CRM system: account_id = AC-7781
Accounting system: debtor_code = CUST-000391
Ticketing system: organization_id = 55392

Asset Mapping allows INTERA to understand that these external records refer to the same real-world business object.

This is important because INTERA often needs to combine signals from multiple systems. A customer dashboard may show billing balance, open tickets, active services, recent payments, usage, contract status, and sales activity. These values may come from different integrations, but they need to be connected to the same INTERA Asset.

Asset Mapping may be based on:

• exact external IDs;
• manually confirmed mappings;
• shared business identifiers;
• normalized names;
• contract numbers;
• product codes;
• account numbers;
• custom transformation logic.

A good integration should expose enough stable identifiers for INTERA to map external data reliably. Poor or unstable mapping can lead to duplicated assets, missing metrics, incorrect dashboard values, and unreliable reconciliation results.

In short, Asset Mapping turns external system records into meaningful INTERA business objects.

What is an Integration Instance? #

An Integration Instance is a configured installation of an Integration Module inside a specific INTERA environment.

The Integration Module defines what an integration can do. The Integration Instance defines how that integration is used in a particular customer setup.

For example, INTERA may have one Integration Module called odoo, but a customer may create several Integration Instances from it:

Odoo - Main Company
Odoo - Cyprus Subsidiary
Odoo - Test Environment
Odoo - Historical Archive

Each Integration Instance may have its own configuration, credentials, API URL, tenant ID, database connection, sync settings, enabled DataSources, and mapping rules.

This distinction is important because developers build Integration Modules, while INTERA users or administrators create Integration Instances.

In practice:

Integration Module = reusable integration package
Integration Instance = configured connection created from that package

A single Integration Module can therefore be reused many times. Each instance connects to a different external environment, account, tenant, database, file source, or company system.

Integration Instances allow INTERA to support real business structures where one organization may have multiple companies, departments, systems, regions, or test environments using the same underlying integration type.