Metrics

Updated 2026-08-1518 min read

Metrics are the values that INTERA monitors over time.

They turn raw external data into useful business information and allow Dashboards to show not only what exists, but what is happening.

A Metric may represent:

a number;
a financial amount;
a percentage;
a status;
a date;
a duration;
a location;
a boolean condition;
a calculated business result.

Examples include:

monthly revenue;
overdue balance;
open ticket count;
service availability;
last payment date;
current vessel position;
billing completion;
network status;
customer health.

This chapter explains:

what a Metric is;
how Metrics receive values;
Metric value types;
Metrics linked to Assets;
calculated and composite Metrics;
synchronization;
schedules;
time periods;
history and trends;
thresholds;
Metric Health;
validation and troubleshooting.

The key principle is:

A Metric should represent one clearly defined business value that can be understood, verified, and monitored over time.

What Is a Metric?

A Metric is a value defined and managed by INTERA.

A Metric has:

a name;
a value type;
a business definition;
a source or calculation;
optional links to an Asset;
a refresh schedule;
a time context;
optional thresholds;
optional health logic;
historical values.

For example:

Metric:
Total Overdue Balance

Type:
Currency

Source:
Accounting DataSource

Value:
€184,250

Last updated:
15.08.2026 17:30

Another example:

Metric:
Open Critical Tickets

Type:
Number

Value:
12

Metrics Versus Asset Fields

Asset fields describe relatively stable properties of an Asset.

Metrics describe changing values.

For example:

Customer Asset

Fields:
Name
Country
Account Manager
Customer Segment

Metrics:
Monthly Revenue
Outstanding Balance
Open Tickets
Customer Health

A useful rule is:

If the value needs history, trend, scheduling, thresholds, or health logic, it should usually be a Metric.

Standalone Metrics

A Metric does not always need to belong to an Asset.

Examples include:

total company revenue;
current cash balance;
total open incidents;
billing completion percentage;
total unpaid provider costs.

These describe the company or an operational process as a whole.

For example:

Metric:
Company Bank Balance

This can exist independently without being attached to a specific Asset.

Asset Metrics

A Metric may belong to an Asset.

For example:

Asset:
Customer — ACME Ltd

Metrics:
Revenue
Debt
Open Tickets
Health

or:

Asset:
Vessel — MV Example

Metrics:
VSAT Status
VSAT Usage
Certus Status
Network Health

This allows the same Metric definition to be applied to many Assets of the same type.

Metric Value Types

Every Metric has a value type.

The type determines:

how the value is stored;
how it is displayed;
which operations are allowed;
which thresholds may be used.

Number

Used for general numeric values.

Examples:

open ticket count;
connected users;
active contracts;
number of alarms.

Example:

Open Tickets = 24

Currency

Used for financial values.

Examples:

revenue;
overdue balance;
bank balance;
provider costs.

Example:

Overdue Balance = €82,150

The currency should always be defined explicitly.

Percentage

Used for values expressed as a proportion.

Examples:

service availability;
billing completion;
collection rate;
SLA compliance.

Example:

Billing Completion = 96.4%

Status

Used when a Metric represents one of several states.

Examples:

Online;
Offline;
Warning;
Critical;
Complete;
Pending.

Example:

Network Status = Online

Status values should use a controlled set of options.

Boolean

Used for a simple true/false condition.

Examples:

Billing Ready;
Backup Completed;
Service Active.

Example:

Billing Ready = true

Date and Time

Used for events or deadlines.

Examples:

next billing run;
last payment;
last successful backup;
next inspection.

Example:

Last Payment Date = 14.08.2026

Duration

Used to represent elapsed time.

Examples:

average ticket resolution time;
current outage duration;
processing time.

Example:

Average Resolution Time = 2h 18m

Text

Used when the result is primarily descriptive.

Examples:

current operational note;
latest error description;
current provider name.

Text Metrics should be used sparingly because they are harder to aggregate and compare.

Coordinates

Used for geographic location.

Examples:

vessel position;
vehicle position;
site coordinates.

A coordinates Metric may contain latitude and longitude.

Metric Display Name

A Metric may have an internal definition name and a cleaner display name.

For example:

Internal Metric:
monthly_overdue_customer_balance_eur

Display Name:
Overdue Balance

Dashboards should normally use the display name.

Role Packages may provide role-specific display names so the same Metric can be presented differently in different contexts.

How a Metric Gets Its Value

A Metric may obtain its value in several ways.

Typical methods include:

manual entry;
DataSource synchronization;
aggregation;
calculation from other Metrics;
logical conditions;
formulas;
health calculations.

Manual Metrics

A manual Metric is updated by a user.

Examples include:

approval complete;
commission paid;
management risk level;
readiness confirmed.

Manual Metrics are useful when the value cannot be obtained from an external system.

For a manual Metric, define:

who can edit it;
allowed values;
whether comments are required;
how long the value remains valid.

Synchronized Metrics

A synchronized Metric receives its value from a DataSource.

A typical synchronized Metric contains:

Integration Instance;
DataSource;
filters;
result field;
aggregation;
time context;
schedule.

For example:

Metric:
Open Tickets

Integration:
Customer Support Production

DataSource:
Tickets

Filter:
Status = Open

Operation:
Count

Aggregation

A DataSource may return many records.

A Metric often converts them into one result.

Common aggregation types include:

count;
sum;
average;
minimum;
maximum;
earliest value;
latest value.

Count

Use Count to measure the number of matching records.

Examples:

open incidents;
active customers;
overdue invoices;
unresolved alarms.

Sum

Use Sum to total numeric values.

Examples:

revenue;
overdue balance;
sales amount;
usage volume.

Average

Use Average for mean values.

Examples:

average invoice size;
average ticket age;
average response time.

Minimum and Maximum

Use these for extremes.

Examples:

oldest overdue invoice;
highest customer debt;
lowest stock level.

Filters

Filters determine which records are included.

For example:

Metric:
Overdue Invoice Count

DataSource:
Invoices

Filters:
Status = Unpaid
Due Date < Today

Operation:
Count

Filters should be explicit and easy to understand.

Avoid business definitions that depend on hidden assumptions.

Time Context

Every time-dependent Metric should have a clear period definition.

Examples include:

current day;
current week;
current month;
previous month;
rolling 30 days;
billing period;
invoice due-date window;
production shift;
custom fiscal period.

A Metric should never rely only on a vague term such as:

Current period

unless the Role Package or Metric definition explicitly defines what that means.

Calendar Periods

Common calendar periods include:

today;
yesterday;
week to date;
month to date;
previous month;
year to date.

For example:

Monthly Revenue

Period:
Current calendar month

Business Periods

Some systems use business-specific periods.

Examples include:

billing cycle;
accounting period;
voyage;
production batch;
shift;
delivery window.

For example:

Billing Completion

Period:
Current billing run

The period should match the business process, not just the calendar.

Calculated Metrics

A calculated Metric is based on one or more other values.

For example:

Gross Margin =
Revenue - Costs

or:

Collection Rate =
Paid Amount / Invoiced Amount × 100

Calculated Metrics are useful for combining source data into a business result.

Metrics Based on Other Metrics

A Metric can use another Metric as an input.

For example:

Metric A:
Revenue

Metric B:
Costs

Metric C:
Profit = Revenue - Costs

This makes complex business logic easier to understand and reuse.

Logical Metrics

A Metric may return a condition based on one or more values.

For example:

If Open Tickets > 100
Then Status = Critical
Else Status = Normal

or:

If Billing Completion >= 99%
Then Billing Ready = true

Logical Metrics are useful for status, readiness, and alerting.

Formula-Based Metrics

More complex calculations can use formulas.

For example:

Usage Percentage =
monthly_vsat_used_gb
/
monthly_vsat_allowance_gb
× 100

A formula may contain several operators and references to fields or Metrics.

Depending on the current INTERA version, formulas may be configured through:

a visual formula editor;
YAML;
a combination of both.

Composite Metrics

A composite Metric combines several inputs into one result.

Examples include:

customer health;
vessel health;
company health;
operational readiness.

A composite Metric may use:

normalized values;
weights;
thresholds;
formulas;
logical rules.

For example:

Company Health

Financial Health: 30%
Network Health: 30%
Support Health: 20%
Billing Health: 20%

The final result may be expressed as a score between 0 and 100%.

Metric Health

Metric Health converts the raw Metric value into a normalized indication of whether the value is good or bad.

For example:

Metric:
Service Availability

Value:
99.2%

Health:
92%

The raw value and health value are different.

The Metric tells you:

What is the value?

The health score tells you:

How good or bad is this value?

Health Normalization

Different Metrics use different scales.

For example:

Revenue:
€420,000

Open Tickets:
24

Availability:
99.5%

These cannot be directly combined.

Health normalization converts them to a common scale.

For example:

Revenue Health:
85%

Ticket Health:
70%

Availability Health:
96%

These values can then be combined into Asset Health or another composite Metric.

Thresholds

Thresholds define how Metric values should be interpreted.

For example:

Open Tickets

0–20:
Normal

21–40:
Warning

41+:
Critical

Another example:

Service Availability

99.5% and above:
Healthy

98.0–99.49%:
Warning

Below 98.0%:
Critical

Thresholds should reflect business requirements, not arbitrary technical values.

Direction Matters

For some Metrics, higher is better.

Examples:

revenue;
availability;
collection rate.

For others, lower is better.

Examples:

overdue balance;
open tickets;
outage duration.

Health configuration must define the correct direction.

Weighted Health

When multiple Metrics contribute to a health score, each may have a weight.

For example:

Vessel Health

Network Status: 40%
Usage Level: 20%
Open Incidents: 25%
Equipment Status: 15%

The weights should total 100%.

Higher weights mean the Metric has a greater effect on the final health result.

Asset Health

Asset Health is a dedicated health Metric defined at the Asset Type level.

Each Asset of that type receives its own health result.

For example:

Asset Type:
Vessel

Health Inputs:
VSAT Status
Certus Status
Monthly Usage
Open Incidents

Then each vessel receives its own health Metric:

MV Example Health = 91%

MV Demo Health = 64%

MV Test Health = 28%

This allows Asset Lists and Dashboards to quickly highlight which Assets require attention.

Metric History

INTERA stores Metric history where configured.

Historical values allow users to see:

changes over time;
trends;
previous values;
seasonal patterns;
abnormal changes.

For example:

Monthly Revenue

May:
€380,000

June:
€405,000

July:
€420,000

Trend

A Metric may compare its current value against a reference period.

Trend types may include:

previous value;
rolling 1 week;
rolling 2 weeks;
rolling 1 month;
rolling 1 quarter;
rolling 6 months;
rolling 1 year;
rolling lifetime;
fixed period;
same period last year.

A trend may indicate:

increase;
decrease;
no meaningful change.

Trend Direction Does Not Always Mean Good or Bad

An upward trend is not always positive.

For example:

Revenue ↑

is usually positive.

But:

Open Incidents ↑

is usually negative.

Trend direction and health direction are separate concepts.

Previous Value

This compares the current Metric value with the immediately preceding stored value.

Example:

Current:
€120,000

Previous:
€115,000

Trend:
+4.3%

Rolling Period Trends

Rolling trends compare the current value with a rolling historical period.

Examples:

rolling 1 week;
rolling 1 month;
rolling 1 year.

These are useful for smoothing short-term fluctuations.

Same Period Last Year

This compares the current business period with the equivalent period one year earlier.

Example:

August 2026 Revenue:
€420,000

August 2025 Revenue:
€395,000

Trend:
+6.3%

This is useful where seasonality matters.

Fixed Period

A Metric may compare against a manually defined reference period.

For example:

Current quarter
vs
Q1 2026

This is useful for planned benchmarks or special analysis.

Synchronization Schedule

A synchronized Metric must define when it should refresh.

INTERA supports scheduled updates.

A Metric may:

use the system default schedule;
define its own schedule;
disable scheduled updates.

System Default Schedule

The system default provides a convenient refresh schedule for Metrics that do not need special timing.

For example:

System Default:
Every 60 minutes

A Metric can use this setting without defining its own timer.

Metric-Specific Schedule

A Metric may override the system default.

Examples:

Network Status:
Every 5 minutes

Bank Balance:
Every hour

Monthly Revenue:
Every day at 06:00

Use a custom schedule only when there is a business reason.

Disable Scheduled Updates

Some Metrics do not need automatic refresh.

Examples:

manually maintained Metrics;
closed accounting periods;
special audit Metrics;
testing Metrics.

Scheduled updates can be disabled.

The Metric may still be refreshed manually where supported.

Choosing an Update Frequency

The correct schedule depends on:

how quickly the source data changes;
how quickly users need to see the change;
external API limits;
source-system load;
Metric importance.

Do not refresh every Metric as frequently as possible.

A Metric should update frequently enough to support the business decision it serves.

Data Freshness

A Metric value may be correct but too old to be useful.

INTERA should therefore track the last successful update time.

For example:

Bank Balance:
€245,000

Last updated:
14.08.2026 09:00

If the current time is the next day, the value may no longer be operationally reliable.

Stale Metrics

A Metric may be considered stale when it has not refreshed within an expected period.

Examples:

network status older than 10 minutes;
bank balance older than 4 hours;
daily revenue older than 2 days.

Staleness limits should match the Metric’s business purpose.

Metric Status

A Metric may have a technical status separate from its value.

Possible statuses include:

valid;
delayed;
synchronization error;
permanent error;
disabled.

Valid

The Metric updated successfully.

Delayed

The Metric has not refreshed within its expected time.

Synchronization Error

The latest refresh attempt failed.

INTERA may still display the previous value.

Permanent Error

The Metric cannot update until configuration is corrected.

Possible causes include:

missing Integration;
deleted DataSource;
removed field;
invalid mapping;
unsupported formula.

Disabled

Scheduled updates have been intentionally turned off.

Metric Errors and Retry Behaviour

Temporary synchronization errors may be retried automatically depending on configuration.

Examples include:

network timeout;
temporary API failure;
external server unavailable.

A permanent configuration problem should not be retried indefinitely.

Examples include:

invalid credentials;
missing DataSource;
deleted field;
invalid formula.

Administrators should review repeated failures instead of relying only on automatic retry.

Metric Categories

Metrics may be organized using Categories.

Categories provide a simple visual classification system.

A Metric may have:

no Category;
one Category;
several Categories.

Categories can be represented by color indicators.

For example:

Red:
Critical Operations

Blue:
Finance

Green:
Commercial

Category names are administrator-defined.

Categories Are Independent of Role Packages

A Metric may belong to:

one or more Categories;
a Role Package;
an Integration;
an Asset.

These are different classifications.

For example:

Metric:
Overdue Balance

Category:
Finance

Role Package:
Finance Manager

Integration:
Business Central

Asset:
Customer

Favorites

Users may mark important Metrics as Favorites where supported.

Favorites provide a quick way to find frequently used Metrics without changing their underlying classification.

Metric Library

The Metric Library provides a centralized view of available Metrics.

It may support views such as:

all Metrics;
Favorites;
by Category;
by Role Package;
by Integration.

The library may also provide:

search;
filtering;
sorting;
Library and Compact views.

The Metric Library is intended to help administrators find and manage Metrics without opening individual Dashboards.

Creating a Metric

A typical creation process is:

open the Metric Library;
select New Metric;
enter the name;
select the value type;
define the source or calculation;
configure the time context;
configure the schedule;
define thresholds if required;
configure health if required;
save;
run a test update;
validate the result.

Name the Metric Clearly

A Metric name should describe exactly what it measures.

Good:

Monthly Revenue
Open Critical Tickets
Total Overdue Balance
Current Bank Balance

Poor:

Value 1
Status
Main Number
Current Total

Add a Business Definition

Important Metrics should include a description.

For example:

Total unpaid EUR value of invoices whose due date is before today,
excluding cancelled invoices.

This makes the Metric easier to validate and maintain.

Choose the Correct Type

Do not store:

"92%"

as text if the value is really a percentage.

Use:

Type:
Percentage

Value:
92

Correct types allow proper:

formatting;
comparison;
trends;
thresholds;
formulas.

Configure the Source

For a synchronized Metric:

select the Integration Instance;
select the DataSource;
configure filters;
select the result field;
select the aggregation.

For example:

Integration:
Business Central Production

DataSource:
Invoices

Filter:
Payment Status = Unpaid

Field:
Remaining Amount

Aggregation:
Sum

Preview Source Data

Where available, use DataSource preview before saving the Metric.

Check:

sample records;
field names;
data types;
returned values;
filters.

This is often the fastest way to identify configuration mistakes.

Validate the Result

After creating the Metric:

run a manual update;
compare the result with the source system;
verify the time period;
verify filters;
verify aggregation;
verify units or currency;
check the last-update time;
inspect the Metric on a Dashboard.

A technically successful update does not automatically mean the result is correct.

Example: Open Tickets Metric

Name:
Open Tickets

Type:
Number

Integration:
Support Production

DataSource:
Tickets

Filter:
Status = Open

Aggregation:
Count

Schedule:
Every 15 minutes

Example: Monthly Revenue Metric

Name:
Monthly Revenue

Type:
Currency

Currency:
EUR

Integration:
Billing Production

DataSource:
Invoices

Period:
Current billing period

Field:
Net Amount

Aggregation:
Sum

Schedule:
Every day

Example: Service Availability

Name:
Service Availability

Type:
Percentage

Calculation:
Available Time / Total Time × 100

Thresholds:
99.5%+ = Healthy
98.0–99.49% = Warning
Below 98.0% = Critical

Example: Usage Against Allowance

Metric:
VSAT Usage Percentage

Formula:
monthly_vsat_used_gb
/
monthly_vsat_allowance_gb
× 100

This can then be used as an input to Vessel Health.

Example: Customer Health

Customer Health

Inputs:
Outstanding Balance Health — 35%
Service Availability Health — 30%
Open Ticket Health — 20%
Revenue Trend Health — 15%

Each Customer Asset receives its own calculated health value.

Common Metric Modelling Mistakes

Using a Field Instead of a Metric

Problem:

Customer Field:
Outstanding Balance

If the value changes frequently and needs history, it should normally be a Metric.

Using a Metric for Static Description

Problem:

Metric:
Customer Country

Country is normally an Asset field.

Missing Time Context

Problem:

Revenue

Without a defined period, the Metric is ambiguous.

Better:

Monthly Revenue — Current Billing Period

Hidden Business Rules

Problem:

A Metric excludes some invoices but the exclusion is not documented.

Business logic should be explicit.

Overly Complex First Metric

Do not begin with a Metric that combines:

five DataSources;
multiple formulas;
cross-currency conversion;
several time periods.

Validate simple components first.

Excessive Refresh Frequency

A monthly Metric usually does not need to update every minute.

Choose refresh frequency according to operational value.

Treating Trend as Health

A Metric can increase while becoming less healthy.

Keep these concepts separate.

Ignoring Stale Data

A Dashboard can show an old valid value.

Always consider the last-update time.

Editing a Metric

Before changing an existing Metric, review where it is used.

A Metric may be referenced by:

Dashboards;
Widgets;
Asset Health;
calculated Metrics;
Role Packages;
other formulas.

Changing its:

type;
name;
formula;
source;
period;
unit;

may affect dependent configuration.

Test important changes carefully.

Deactivating a Metric

If a Metric is no longer used, disable it instead of deleting it where possible.

This may preserve:

history;
Dashboard references;
audit information;
configuration for future reuse.

Deleting a Metric

Delete a Metric only when:

it was created by mistake;
it is a duplicate;
no required Dashboard or calculation depends on it.

Deleting a Metric may break:

Widgets;
Asset Health;
calculated Metrics;
Role Package definitions.

Metric Naming Best Practices

Use names that reflect business meaning.

Prefer:

Current Bank Balance
Monthly Recurring Revenue
Open Critical Incidents
Billing Completion

Avoid source-specific technical names unless needed.

For example:

BC Table 112 RemainingAmt Sum

may be technically precise but poor for business users.

The source configuration can contain the technical details.

The Metric name should remain readable.

Metric Design Checklist

Before publishing a Metric, verify:

the name is clear;
the value type is correct;
the business definition is documented;
the source is correct;
filters are correct;
the time context is explicit;
aggregation is correct;
schedule is appropriate;
currency or unit is defined;
thresholds are meaningful;
health direction is correct;
history is enabled where useful;
trend type is appropriate;
the result has been validated against the source system.

Recommended First Metric

Choose a Metric that is:

simple;
easy to verify;
useful to a real user;
based on one DataSource.

Good examples:

Open Tickets

Total Unpaid Balance

Current Bank Balance

Active Customer Count

Avoid starting with a complex health score.

First confirm that basic Metric synchronization works correctly.

Recommended Metric Development Sequence

Use this sequence:

define the business question;
define the Metric name;
choose the value type;
choose the source;
define filters;
define the time context;
define aggregation or formula;
test the raw result;
configure the schedule;
enable history if required;
add thresholds;
configure health if required;
add trend;
display it on a Dashboard;
validate with the business owner.

Best Practices

Keep One Business Meaning Per Metric

A Metric should answer one clear question.

Separate Raw Value and Health

Keep the real business value visible.

Do not replace:

Open Tickets = 42

with only:

Health = 63%

Both may be useful.

Define Time Explicitly

Time context is part of the Metric definition, not an optional filter.

Reuse Metrics

If several Dashboards need the same value, define the Metric once and reuse it.

Validate with the Source System

Always compare important Metrics with their original data.

Use History Selectively

History is useful for values that change meaningfully over time.

Not every temporary status needs long-term history.

Use Health for Interpretation

Health is most useful when the raw value alone does not immediately tell the user whether the situation is acceptable.

Naming changed in v0.003

KPI is now Metric across the product and the docs. Existing roles were migrated automatically; saved dashboards keep working.