Dashboards

Updated 2026-08-1516 min read

Dashboards are the main way users interact with INTERA.

They bring together Assets, Metrics, status information, lists, charts, and navigation into a role-specific operational view.

A Dashboard is not intended to reproduce the interface of an external system. It should present the information a user needs to understand the current situation and decide where attention is required.

This chapter explains:

what a Dashboard is;
how Dashboard pages are structured;
how Frames and Widgets work;
how Metrics and Assets are displayed;
how Dashboard access is controlled;
how navigation works;
how to design useful operational views;
common Dashboard design mistakes.

The key principle is:

A Dashboard should help a user understand what requires attention without searching through multiple systems.

What Is a Dashboard?

A Dashboard is a collection of visual elements organized around a business role or task.

Examples include:

Finance Overview;
Billing Operations;
Service Assurance;
Fleet Performance;
Customer Operations;
Network Operations;
Management Overview.

A Dashboard may contain:

one or more pages;
Frames;
Widgets;
Metrics;
Asset lists;
tables;
charts;
status indicators;
navigation controls.

For example:

Dashboard:
Finance Overview

Pages:
Overview
Collections
Cash
Exceptions

Each page may show a different part of the same business responsibility.

Dashboards Are Role-Based

INTERA Dashboards are designed around business roles.

A Finance Manager may need:

bank balance;
overdue customer debt;
expected collections;
supplier liabilities.

A Service Assurance Manager may need:

service availability;
critical incidents;
affected customers;
network health.

A Fleet Manager may need:

vessel status;
communications availability;
open incidents;
vessel health.

The same source system may therefore contribute data to several Dashboards.

Dashboards Are Not Source-System Screens

Avoid designing a Dashboard around the structure of an external system.

For example, do not create:

Billing Dashboard
CRM Dashboard
Accounting Dashboard
Support Dashboard

unless users genuinely work by system.

Prefer business-purpose Dashboards such as:

Revenue Assurance
Customer Operations
Service Assurance
Finance Overview

These can combine information from several Integrations.

Dashboard Structure

A Dashboard is typically organized as:

Dashboard
    ↓
Page
    ↓
Frame
    ↓
Widget

Each level has a specific purpose.

Pages

A Dashboard may contain one or more pages.

Pages separate different views while keeping them within the same Dashboard.

For example:

Dashboard:
Service Assurance

Pages:
Overview
Critical Incidents
Customers
Network
Trends

Users can move between pages without leaving the Dashboard.

Use Pages for Meaningful Separation

Create a new page when the information represents a distinct view or task.

Good examples:

Overview;
Exceptions;
Customers;
Providers;
Historical Trends.

Avoid creating a new page for every small group of Metrics.

Too many pages make navigation slower and harder to understand.

Dashboard Overview Page

The first page should normally provide the quickest summary.

An effective overview page may contain:

overall health;
a small number of critical Metrics;
current alerts or exceptions;
important Asset status;
links to more detailed pages.

The user should be able to answer:

Is everything normal?

and, if not:

Where should I look next?

within a few seconds.

Frames

Frames organize Widgets into visual sections.

A Frame may represent:

a subject;
a business area;
an Asset group;
a status area;
a group of related Metrics.

For example:

Finance Overview

Frame:
Cash Position

Widgets:
Current Bank Balance
Expected Receipts
Provider Payments

Another example:

Service Assurance

Frame:
Critical Services

Widgets:
Service Availability
Open Critical Incidents
Affected Customers

Frame Titles

Use short and meaningful titles.

Good:

Cash Position;
Billing Readiness;
Network Health;
Critical Customers.

Poor:

Frame 1;
Metrics;
Information;
Data.

A user should understand what the Frame represents without reading every Widget.

Widgets

Widgets are the individual visual components placed inside Frames.

A Widget may show:

one Metric;
several Metrics;
an Asset;
an Asset list;
a table;
a chart;
a status;
text;
navigation;
another supported visualization.

Different Widget types are designed for different kinds of information.

Metric Widgets

A Metric Widget displays a Metric value.

It may show:

display name;
current value;
unit;
health;
trend;
last-update status;
threshold state.

For example:

Overdue Balance

€184,250
↑ 6.2% vs last month
Health: 62%

The exact appearance depends on the Widget type.

Status Widgets

Status Widgets are useful for values such as:

Online;
Offline;
Warning;
Critical;
Ready;
Delayed.

They should make the current state immediately recognizable.

Avoid using many different colors or symbols for the same meaning across different Dashboards.

Asset Widgets

An Asset Widget displays information about one Asset.

For example:

Vessel:
MV Example

Health:
82%

VSAT:
Online

Open Incidents:
2

Asset Widgets are useful where a specific business object needs dedicated attention.

Asset List Widget

An Asset List displays multiple Assets in a compact operational view.

Each row normally represents one Asset.

For example:

Vessel          Health   VSAT     Certus   Usage   Incidents
MV Alpha        92%      Online   Online   72%     0
MV Beta         61%      Online   Offline  88%     2
MV Gamma        28%      Offline  Online   95%     4

Asset Lists are useful when users need to scan many similar Assets quickly.

Examples include:

vessels;
customers;
network sites;
vehicles;
suppliers;
products.

Asset List Groups

An Asset List may organize each row into several display groups.

For example:

Group 1:
Vessel Name

Group 2:
VSAT Status
VSAT Usage

Group 3:
Certus Status
Certus Usage

Group 4:
Open Incidents

A group can contain one or more values.

This allows administrators to decide which information should appear together.

Asset Health in Lists

Asset Health is particularly useful in large lists.

A visual health indicator may allow users to immediately identify:

healthy Assets;
Assets requiring attention;
critical Assets.

For example, a health indicator may appear as:

a vertical status bar;
a colored icon;
a percentage;
a status label.

The exact presentation depends on the Widget design.

Tables and Grid Widgets

A Grid Widget displays records from a DataSource in table form.

For example:

Invoice   Customer   Due Date   Amount   Status
100221    ACME       10.08.26   €4,200   Overdue
100228    Delta      12.08.26   €8,100   Overdue

Grid Widgets are useful when users need to inspect individual records rather than only aggregated Metrics.

Grid Features

Depending on the Widget version, a Grid may support:

column selection;
column reordering;
sorting;
paging;
quick search;
filtering;
grouped output;
cell formatting;
status icons;
images;
responsive sizing.

Charts

Charts are useful when patterns over time are more important than individual values.

Examples include:

revenue trend;
ticket volume;
availability over time;
usage growth;
health history.

Use charts where the visual pattern adds information.

Do not use a chart simply because data can be charted.

Dashboard Layout

Dashboard pages are built using predefined layout sizes.

Widgets may support sizes such as:

full width;
half width;
one third;
one quarter.

A Widget should automatically adapt to the space assigned by the Dashboard.

Use Large Widgets for Complex Information

Use full or half-width Widgets for:

large tables;
Asset Lists;
charts;
complex operational views.

Use smaller sizes for:

individual Metrics;
simple statuses;
compact indicators.

Responsive Behaviour

INTERA may be used on screens of different sizes.

Widgets should adapt to the available space.

When designing a Dashboard, check that:

values are readable;
labels are not unnecessarily long;
tables remain usable;
important information remains visible;
small Widgets are not overloaded.

Widget Configuration

Widgets define which parameters they support.

Depending on the Widget, configuration may include:

source Metric;
DataSource;
Asset Group;
title;
visible fields;
formatting;
filters;
sorting;
display options;
size behaviour;
interaction settings.

The visual Widget editor may expose these options through tabs and sections.

Visual Editor and YAML

Dashboard and Widget configuration may be edited through visual tools.

Some advanced configurations may still require YAML.

Where YAML editing is available, the YAML remains the authoritative configuration representation.

If a visual editor cannot safely interpret a configuration, it may switch to YAML-only editing.

Administrators should avoid editing YAML directly unless they understand the configuration structure.

Widget Formatting

Widgets may support formatting options such as:

bold text;
indentation;
alignment;
color;
number formatting;
date formatting;
currency formatting;
visibility of headers.

Formatting should improve readability, not add decoration.

Color Usage

Color is most useful when it has a consistent operational meaning.

For example:

healthy;
warning;
critical;
offline.

Avoid using strong colors only for visual variety.

If red means critical status in one Widget, it should not mean a neutral category in another nearby Widget unless the distinction is very clear.

Dashboard Navigation

Dashboards may contain several pages and links between them.

Navigation may be provided through:

page tabs;
navigation menus;
clickable Widgets;
on_click actions.

For example:

Overview
    ↓ click Critical Customers
Customer Exceptions Page

Good navigation allows users to move from summary to detail.

on_click Behaviour

A Widget may define an action when the user clicks it.

Possible actions may include:

open another Dashboard page;
open a more detailed view;
show Asset information;
navigate to another Dashboard;
open an external URL where supported.

The available actions depend on the Widget and current INTERA version.

Summary-to-Detail Design

A good Dashboard often follows this pattern:

High-level status
       ↓
Exception list
       ↓
Detailed records

For example:

Company Health
       ↓
Critical Customers
       ↓
Customer Details

This is more useful than placing all available data on one page.

Filters

Some Widgets may allow users to filter the displayed data.

Examples include:

all Assets;
assistance required;
critical only;
active only;
specific region;
Asset Group.

For example, an Asset List may provide:

Show:
All
Assistance Required
Critical
Offline

Filters should reflect useful operational questions.

Search

Large tables and Asset Lists may provide quick search.

Search is useful for finding:

Asset name;
customer;
vessel;
product;
invoice;
reference number.

Search should complement structured filters rather than replace them.

Dashboard Access Control

Dashboard access is controlled through Roles.

For example:

Dashboard:
Finance Overview

Roles:
Finance Manager
CFO

Users without one of the required Roles should not see the Dashboard.

Multiple Roles

A user may have several Roles.

For example:

User:
Operations Director

Roles:
Service Assurance Manager
Network Operations Manager
Management Overview

The user receives access to Dashboards assigned to any of these Roles.

Access Is Different from Data Modelling

Do not create duplicate Metrics or Assets only because different Roles need to see them.

For example:

Monthly Revenue Metric

can be reused in:

Finance Dashboard;
Management Dashboard;
Sales Dashboard.

Access is controlled at the Dashboard and Role level.

Dashboard Naming

Use names based on business purpose.

Good examples:

Finance Overview;
Revenue Assurance;
Service Assurance;
Billing Operations;
Fleet Overview.

Avoid:

Dashboard 1;
New Dashboard;
Main Screen;
Test Dashboard.

Page Naming

Page names should be short.

Good:

Overview;
Customers;
Exceptions;
Trends;
Providers;
Incidents.

Avoid very long descriptions in navigation.

Dashboard Design Principles

A useful Dashboard should answer three questions:

What is happening?
Is anything wrong?
Where should I investigate?

If the user cannot answer these quickly, the Dashboard may contain too much information or lack clear hierarchy.

Start with the Most Important Information

The most important information should appear first.

Typical priority:

1. Health / overall status
2. Critical exceptions
3. Key Metrics
4. Operational detail
5. Historical analysis

Do not place the most critical status at the bottom of a long page.

Design for Exceptions

Operational Dashboards are often most useful when they highlight what is not normal.

For example:

40 vessels

36 Healthy
3 Need Attention
1 Critical

The user should quickly find the four Assets requiring attention rather than manually reviewing all 40.

Do Not Overload the Overview

Avoid placing every available Metric on the first page.

An overview should show only enough information to understand the current state.

Detailed Metrics can be placed on secondary pages.

Group Related Information

Place related information together.

For example:

Frame:
Collections

Metrics:
Overdue Balance
Overdue Invoice Count
Oldest Overdue Invoice
Collection Rate

This is clearer than scattering these values across the page.

Use Consistent Layouts

Similar Dashboards should use similar design patterns.

For example, all role-based Dashboards may use:

health summary at top left;
critical exceptions at top right;
detailed operational Frames below.

Consistency reduces the time required for users to understand a new Dashboard.

Display Business Names

Prefer business-readable labels.

Good:

Overdue Balance

Poor:

bc_invoice_remaining_amt

Technical field names should remain inside configuration.

Show Units

Always make the unit clear.

For example:

Usage:
124 GB

is better than:

Usage:
124

Similarly:

Availability:
99.4%

and:

Balance:
€184,250

Show Data Freshness Where Important

For time-sensitive information, consider displaying:

last updated;
delayed status;
synchronization error.

For example:

Network Status:
Online

Updated:
2 minutes ago

An old value should not appear as if it were live.

Trends

Metric Widgets may show trend information.

For example:

Monthly Revenue
€420,000
↑ 6.3% vs same month last year

Trend indicators should show both:

direction;
comparison period.

An arrow without context may be misleading.

Health and Trend Are Different

A Metric can improve while still being unhealthy.

For example:

Open Tickets:
78

Trend:
↓ 10%

Health:
Critical

The trend is improving, but the current value is still unacceptable.

Dashboards should not treat these as the same signal.

Dashboard Editing Workflow

A typical Dashboard creation process is:

create the Dashboard;
enter a clear name;
assign Roles;
create the first page;
choose a page layout;
add Frames;
add Widgets;
connect Widgets to Metrics, Assets, or DataSources;
configure formatting;
add additional pages;
configure navigation;
save;
preview;
test access;
publish.

Create a New Dashboard

To create a Dashboard:

open the Dashboard editor;
select New Dashboard;
enter the Dashboard name;
assign the required Roles;
create the first page;
save the Dashboard.

Start with one simple page.

Add a Page

To add another page:

open the Dashboard editor;
select Add Page;
enter the page name;
choose the layout;
add Frames and Widgets;
save.

Add pages only when they improve navigation.

Add a Frame

To create a Frame:

select the page;
choose Add Frame;
enter the Frame title;
select its position and size;
add Widgets.

Frames should organize information by subject.

Add a Widget

To add a Widget:

select the target Frame;
choose Add Widget;
select the Widget type;
select its source;
configure display options;
select the required size;
save.

The available settings depend on the Widget type.

Preview the Dashboard

Before publishing, preview the Dashboard as a user.

Check:

titles;
Widget values;
formatting;
navigation;
page sizes;
data freshness;
role access.

A Dashboard that looks correct in the editor may behave differently with real data.

Test with Realistic Data

Test:

long Asset names;
zero values;
very large numbers;
empty lists;
errors;
offline status;
delayed synchronization;
critical conditions.

Do not test only the ideal state.

Empty States

A Widget should remain understandable when no data is available.

For example:

No critical incidents

is better than a completely blank area.

An empty state should distinguish between:

no matching data;
DataSource failure;
synchronization pending;
permission issue.

Error States

If a Metric or DataSource fails, the Dashboard should make this clear.

Do not silently display:

when the real condition is:

Synchronization failed

Zero and unavailable data have different meanings.

Common Dashboard Design Mistakes

Showing Too Much Information

Problem:

The first page contains dozens of Metrics, several tables, and multiple charts.

Result:

The important information becomes difficult to find.

Use summary-to-detail design.

Organizing by Integration

Problem:

CRM Page
Billing Page
Accounting Page

This forces the user to think like the system architecture.

Prefer business topics.

Duplicate Metrics

Problem:

The same Metric is recreated for several Dashboards.

Use one Metric definition and reuse it.

Too Many Colors

Problem:

Every Widget uses its own color scheme.

Result:

Users cannot understand which colors indicate status.

Keep operational colors consistent.

Too Many Pages

Problem:

Every small detail receives its own page.

Result:

Navigation becomes slow.

Group related content.

Unclear Trend

Problem:

↑ 12%

without explaining the comparison.

Better:

↑ 12% vs previous month

Showing Old Data as Current

Always expose stale or delayed status when freshness matters.

Using Technical Labels

Avoid exposing source-system field names to business users.

Tables Without Prioritization

A list of 500 Assets is rarely useful without:

sorting;
health;
filters;
search;
exception highlighting.

Example: Finance Dashboard

A simple Finance Dashboard could be:

Dashboard:
Finance Overview

Page 1:
Overview

Frame:
Liquidity
- Current Bank Balance
- Expected Receipts
- Planned Payments

Frame:
Collections
- Overdue Balance
- Overdue Invoice Count
- Collection Rate

Frame:
Attention Required
- Critical Customers

A second page could show detailed customer debt.

Example: Service Assurance Dashboard

Dashboard:
Service Assurance

Page 1:
Overview

Frame:
Current Health
- Overall Network Health
- Service Availability
- Critical Incidents

Frame:
Affected Customers
- Customer Asset List

Page 2:
Incidents
- Open Incident Grid

Page 3:
Trends
- Availability Trend
- Incident Volume Trend

Example: Vessel Operations Dashboard

Dashboard:
Fleet Communications

Page:
Overview

Asset List:
All VIP Vessels

Columns / Groups:
Vessel Name
Vessel Health
VSAT Status + Usage
Certus Status + Usage
FBB Status + Usage
IOP Status
Open Incidents

The list can be filtered to:

all vessels;
assistance required;
critical;
offline.

This allows the operator to focus immediately on problem vessels.

Publishing a Dashboard

Before making a Dashboard available to users:

validate every important Metric;
check synchronization;
check Role assignments;
test navigation;
test filters;
test empty states;
test error states;
review labels;
remove test content.

Where draft and published states are supported, keep unfinished Dashboards in draft.

Updating a Dashboard

Dashboard configuration may change as business requirements change.

Before making major changes:

review who uses the Dashboard;
identify important workflows;
preserve the current configuration where possible;
make the change;
preview with real data;
test Role access;
publish.

Avoid changing operational Dashboards during critical business periods without testing.

Removing a Dashboard

Before removing a Dashboard:

identify assigned Roles;
confirm that users no longer need it;
check whether another Dashboard replaces it;
preserve configuration if required;
disable or archive it where possible.

Deletion should be used carefully.

Dashboard Design Checklist

Before publishing, verify:

the Dashboard has a clear purpose;
the target Role is defined;
the overview answers the main operational question;
critical information is visible first;
related information is grouped;
labels are business-readable;
units are visible;
trends include context;
stale data is identifiable;
filters are useful;
navigation works;
empty states are clear;
error states are clear;
access is correct;
real data has been tested.

Recommended First Dashboard

The first Dashboard should be deliberately simple.

For example:

Dashboard:
Finance Overview

Page:
Overview

Metric 1:
Current Bank Balance

Metric 2:
Overdue Balance

Metric 3:
Open Collection Issues

or:

Dashboard:
Customer Operations

Page:
Overview

Metric 1:
Open Tickets

Metric 2:
Critical Tickets

Asset List:
Customers Requiring Attention

The first objective is to confirm that:

Data
  ↓
Metric
  ↓
Widget
  ↓
Dashboard
  ↓
Role
  ↓
User

works correctly from end to end.

Once this is verified, expand the Dashboard gradually.

Best Practices

Design Around Decisions

Ask what the user needs to decide or investigate.

Do not begin with a list of available fields.

Lead with Health and Exceptions

Users should see problems before detail.

Reuse Existing Metrics

Do not duplicate business logic inside Widgets.

Keep Pages Focused

One page should normally represent one clear operational view.

Make Freshness Visible

Old operational data should never look live.

Keep Status Language Consistent

Use the same terms for Healthy, Warning, Critical, Online, Offline, and similar states throughout the system.

Test with the Actual Role

A Dashboard should be validated by someone who understands the business responsibility, not only by the administrator who created it.

Naming changed in v0.003

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