Assets and Data Modelling

Assets are the business objects that INTERA understands and organizes.

They provide structure to information from connected systems and allow Metrics, Dashboards, and Role Packages to work with meaningful business entities.

This chapter explains:

• what Assets are;
• what Asset Types are;
• how Asset fields are defined;
• how Metrics relate to Assets;
• how integrations can provide information used by Assets;
• how to model business objects consistently;
• common data-modelling mistakes.

The key principle is:

Create Assets for business objects that are important to the user and need to be represented consistently across INTERA.

---

What Is an Asset?

An Asset is a business object represented in INTERA.

Examples include:

• customer;
• supplier;
• product;
• vessel;
• vehicle;
• bank account;
• warehouse;
• department;
• network site;
• contract;
• service;
• project.

An Asset has:

• an Asset Type;
• a unique INTERA identity;
• a set of fields;
• optional information supplied by Integrations;
• optional Metrics;
• optional health information;
• optional relationships to other Assets.

For example:

Asset Type: Vessel

Asset:
MV Example

Fields:
IMO Number: 1234567
Operator: Example Shipping Ltd
Flag: Cyprus
Fleet: Mediterranean Fleet
Status: Active

The Asset represents the vessel as a recognizable business object inside INTERA.

---

What Is an Asset Type?

An Asset Type defines the structure of a category of Assets.

Examples include:

• Customer;
• Vessel;
• Product;
• Supplier;
• Network Site;
• Vehicle;
• Contract.

An Asset Type defines which fields its Assets may contain.

For example:

Asset Type: Customer

Fields:
Customer Name
Customer Code
Country
Account Manager
Customer Segment
Status

Every Customer Asset created from this Asset Type follows the same general structure.

---

Asset Types Are Defined by the Administrator

INTERA does not require a fixed universal list of Asset Types.

Administrators can define Asset Types according to the company’s business model.

Role Packages may also provide predefined Asset Types.

For example, a Telecommunications Role Package may provide:

• Customer;
• Product;
• Network Site;
• Service;
• Provider.

A Shipmanagement Role Package may provide:

• Vessel;
• Fleet;
• Port;
• Supplier;
• Service Contract.

The objective is to model business concepts in a way that is meaningful to the organization using INTERA.

---

Asset Fields

Fields store descriptive information about an Asset.

A field may contain:

• text;
• number;
• date;
• status;
• currency;
• percentage;
• coordinates;
• boolean value;
• reference to another Asset;
• another supported value type.

For example:

Asset Type: Vessel

Fields:
Name
IMO Number
Flag
Manager
Current Port
Next Inspection Date
Active

Fields normally describe the Asset itself.

---

Examples of Good Asset Fields

For a Customer:

• name;
• customer code;
• country;
• account manager;
• customer segment;
• contract type.

For a Vessel:

• vessel name;
• IMO number;
• flag;
• operator;
• fleet;
• vessel type.

For a Product:

• product name;
• product code;
• category;
• provider;
• active status.

These values identify or describe the business object.

---

Asset Fields Versus Metrics

A common modelling question is whether a value should be stored as an Asset field or created as a Metric.

A useful distinction is:

A field describes the Asset.
A Metric describes a measurable condition or value associated with the Asset.

For example:

Customer Asset

Fields:
Name
Country
Account Manager
Customer Segment

Metrics:
Outstanding Balance
Monthly Revenue
Open Tickets
Average Response Time

Another example:

Vessel Asset

Fields:
Name
IMO Number
Flag
Fleet

Metrics:
VSAT Usage
Network Availability
Open Service Incidents
Current Health

---

Use a Field for Descriptive Information

Examples include:

• customer name;
• vessel IMO number;
• product category;
• supplier country;
• contract start date;
• assigned manager.

Use fields for information that primarily describes the identity, classification, or properties of the Asset.

---

Use a Metric for Measurable Business Values

Examples include:

• revenue;
• outstanding balance;
• active alarms;
• service availability;
• current network usage;
• open ticket count;
• vessel health;
• stock level.

Metrics are designed for values that may require:

• scheduled updates;
• history;
• trend;
• thresholds;
• health calculations;
• use in Dashboards.

---

Information Supplied by Integrations

Assets may use information provided by connected Integrations.

For example, an Integration may provide information about:

• customers;
• vessels;
• products;
• contracts;
• services;
• network sites.

This information can be used to populate or update relevant Asset fields according to the configuration of the INTERA installation.

For example:

Customer Asset

Customer Name
Customer Code
Segment
Account Manager

may use information supplied by a connected CRM or billing Integration.

The administrator determines which information is relevant to the Asset model.

---

Manual Asset Information

Some Asset information may exist only inside INTERA.

Examples include:

• internal priority;
• strategic customer flag;
• management category;
• local notes;
• responsible manager;
• internal operational classification.

These fields may be entered manually.

Manual fields are useful where the information has a specific INTERA business purpose and is not provided by a connected system.

---

Multiple Sources of Information

An Asset may use information from more than one Integration.

For example, a Customer Asset may use:

• commercial information from a CRM system;
• billing information from a billing platform;
• financial information from accounting;
• support information from a ticketing system.

A Vessel Asset may use:

• vessel details from a fleet-management system;
• connectivity information from a network system;
• usage information from billing;
• support information from a service-management platform.

INTERA presents these values around one business object so that users can work with a consistent view.

---

Source of Truth

When several systems can provide similar information, the administrator should define which source is authoritative for each field or business value.

For example, a customer name may be available in:

• CRM;
• billing;
• accounting.

The company should decide which source is treated as the primary source for that information.

This helps maintain consistent data across Dashboards and workflows.

---

Asset Relationships

Assets may have relationships with other Assets.

Examples include:

Customer
    ↓ has
Contract

Fleet
    ↓ contains
Vessel

Provider
    ↓ supplies
Product

Customer
    ↓ uses
Service

Relationships allow Dashboards and Metrics to reflect real business structures.

---

Parent and Child Assets

Some Asset Types naturally form hierarchies.

For example:

Company
  └── Department
       └── Team

or:

Fleet
  └── Vessel

or:

Customer
  └── Contract
       └── Service

Use hierarchy when it reflects a meaningful and stable business relationship.

Avoid creating hierarchy only for visual organization.

---

Metrics Attached to Assets

A Metric may belong to an Asset.

For example:

Asset:
Customer — ACME Ltd

Metrics:
Monthly Revenue
Outstanding Balance
Open Tickets
Customer Health

Or:

Asset:
Vessel — MV Example

Metrics:
VSAT Status
Monthly VSAT Usage
Certus Status
Open Incidents
Vessel Health

This allows the same business measurement logic to be applied consistently across Assets of the same type.

---

Asset Health

An Asset Type may define how Asset Health is calculated.

Asset Health represents an overall indication of the Asset’s current condition.

For example, Vessel Health may combine:

• network availability;
• data usage;
• open service incidents;
• equipment status.

Customer Health may combine:

• overdue balance;
• support incidents;
• service availability;
• revenue trend.

Health logic belongs to the Asset Type so that Assets of the same type can be evaluated consistently.

Detailed Health configuration is covered in the Metrics chapter.

---

Asset Groups

Assets may be organized into groups for filtering and Dashboard presentation.

Examples include:

• VIP Customers;
• Mediterranean Fleet;
• Critical Network Sites;
• Strategic Suppliers;
• Premium Products.

Asset Groups are useful for Widgets such as Asset Lists and for applying business-specific views.

---

Asset Categories and Classification

Asset Types may contain classification fields.

For example:

Customer Segment:
Enterprise
SME
Retail

or:

Vessel Type:
Container
Tanker
Bulk Carrier

These fields allow users to:

• filter Assets;
• create groups;
• compare Metrics;
• organize Dashboards.

Use controlled values where consistency is important.

---

Designing an Asset Type

Before creating an Asset Type, answer the following questions.

What Business Object Does It Represent?

The Asset Type should represent a clear business concept.

Good examples:

• Customer;
• Vessel;
• Product;
• Supplier.

Poor examples:

• Things;
• Information;
• Current Status;
• Monthly Revenue.

Monthly Revenue is a Metric, not an Asset Type.

---

Does the Object Need to Be Represented Consistently?

An Asset is useful when INTERA needs a stable way to refer to the same business object throughout:

• Dashboards;
• Metrics;
• Role Packages;
• multiple Integrations;
• operational workflows.

For example, a Vessel or Customer may appear in many different views but should remain the same recognizable Asset throughout INTERA.

---

Will Several Metrics Belong to It?

Assets are particularly useful when several Metrics describe the same business object.

For example:

Customer

Revenue
Debt
Open Tickets
Health

or:

Vessel

Connectivity Status
Usage
Incidents
Health

This creates a clear and reusable business model.

---

Recommended Asset Type Fields

Most Asset Types should contain a small set of meaningful core fields.

Typical examples include:

• display name;
• unique business code;
• active status;
• category;
• description;
• responsible person or unit.

Add business-specific fields only when they provide useful context to users or Metrics.

---

Required and Optional Fields

An Asset Type may define required fields.

For example:

Vessel

Required:
Name
IMO Number

Optional:
Flag
Fleet
Operator

Use required fields only for information that is necessary to identify or use the Asset correctly.

Too many required fields can make administration unnecessarily difficult.

---

Field Types

Choose the correct field type.

Examples:

Name → Text
IMO Number → Text
Commission Date → Date
Active → Boolean
Latitude → Number
Longitude → Number

Do not store structured values as free text when a specific type is available.

For example:

Poor:
Active = "yes"

Better:
Active = true

Correct field types improve:

• validation;
• filtering;
• presentation;
• consistency.

---

Controlled Values

Where a field should contain only a defined set of values, use a controlled list where supported.

For example:

Status:
Active
Suspended
Inactive

This is better than allowing several inconsistent variations such as:

active
ACTIVE
running
yes

Controlled values improve filtering and reporting.

---

Naming Conventions

Use clear and consistent names.

For Asset Types:

Customer
Vessel
Product
Supplier

For Asset fields:

Customer Name
Customer Code
Account Manager
Contract Start Date

Avoid internal abbreviations unless they are widely understood.

For example:

Poor:
Cust No.
AcctMgr

Better:

Customer Number
Account Manager

---

Example: Modelling a Vessel

A useful model may be:

Asset Type:
Vessel

Fields:
Vessel Name
IMO Number
Flag
Fleet
Operator
Active

Metrics:
VSAT Status
VSAT Monthly Usage
VSAT Monthly Allowance
Certus Status
FBB Status
Open Incidents
Network Health

The fields describe the vessel.

The Metrics describe measurable operational conditions associated with it.

---

Example: Modelling a Customer

Asset Type:
Customer

Fields:
Customer Name
Customer Code
Segment
Country
Account Manager
Active

Metrics:
Monthly Revenue
Outstanding Balance
Open Tickets
Service Availability
Customer Health

This provides users with a consistent business view of the Customer within INTERA.

---

Example: Modelling a Product

Asset Type:
Product

Fields:
Product Name
Product Code
Category
Provider
Active

Metrics:
Monthly Revenue
Active Customer Count
Usage
Support Cases
Product Health

This allows a Product Dashboard to combine information from different business areas around the same Product Asset.

---

Model Business Concepts, Not Software Systems

When several systems contain information about the same business concept, the INTERA model should normally focus on the business concept.

For example, prefer:

Customer
Product
Vessel

rather than creating separate business models based only on the names of the connected applications.

The purpose of the Asset model is to make INTERA understandable to business users.

---

Avoid Copying Every External Field

A connected system may expose many fields.

This does not mean that every available field needs to become part of an Asset Type.

Include fields that are useful for:

• identification;
• filtering;
• Dashboards;
• Metrics;
• business context;
• decision-making.

A smaller, clearer Asset model is easier to understand and maintain.

---

Asset Creation

Assets may be created through supported INTERA administration workflows.

Depending on the configuration, Asset information may be:

• entered manually;
• supplied by an Integration;
• provided as part of a Role Package;
• imported through supported tools.

The exact workflow depends on the installed INTERA version and Integration.

---

Manual Creation

Manual creation is suitable for:

• small Asset populations;
• strategic business objects;
• testing;
• information managed directly in INTERA.

For example:

Create Asset

Type:
Vessel

Name:
MV Example

IMO:
1234567

---

Editing an Asset

When editing an Asset:

• update manual fields where required;
• review information supplied by Integrations;
• review attached Metrics;
• confirm classifications and relationships;
• check current health where available.

Fields managed by an Integration may be updated again during later synchronization.

---

Deactivating an Asset

An Asset may become inactive.

Examples include:

• customer account closed;
• vessel sold;
• product discontinued;
• supplier relationship ended.

Where possible, mark the Asset inactive rather than deleting it.

This can preserve useful historical and operational context.

---

Deleting an Asset

Delete an Asset only when:

• it was created by mistake;
• it is a duplicate;
• no required history or configuration depends on it.

Deleting an Asset may affect:

• Metrics;
• Dashboards;
• relationships;
• Role Package configuration.

Use deletion carefully.

---

Duplicate Assets

Duplicate Assets can make Dashboards and Metrics difficult to interpret.

For example:

Customer:
ACME Ltd

Customer:
ACME Limited

may refer to the same real company.

Administrators should use:

• consistent naming;
• business identifiers;
• clear source configuration;
• manual review where necessary.

The objective is to maintain a clean and understandable business model.

---

Data Modelling and Role Packages

Role Packages may define:

• Asset Types;
• required fields;
• required Metrics;
• Dashboard expectations;
• Integration requirements.

For example, a Telecommunications Role Package may require:

Asset Type:
Customer

Required fields:
Customer ID
Customer Name

Required Metrics:
Revenue
Debt
Open Tickets

The administrator connects these requirements to the company’s available information and Integrations.

The Role Package defines the business meaning.

---

Data Modelling and Time

Assets usually represent business objects that remain meaningful over time.

Metrics represent changing measurements associated with those objects.

For example:

Asset:
Customer — ACME Ltd

may remain the same business object while:

Monthly Revenue
Outstanding Balance
Open Tickets

change over time.

Use Metric history to represent changing measurements rather than creating separate Assets for different reporting periods.

---

Common Modelling Mistakes

Storing Dynamic Values as Fields

Problem:

Customer Field:
Outstanding Balance

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

Prefer:

Customer Metric:
Outstanding Balance

---

Using a Metric for Static Description

Problem:

Metric:
Customer Country

Country is normally an Asset field.

---

Creating Software-Specific Business Models

Problem:

Creating separate business concepts such as:

CRM Customer
Billing Customer
Accounting Customer

when users simply need to work with the concept of:

Customer

Prefer business-oriented modelling unless the distinctions have genuine business meaning.

---

Copying Too Much Source Data

Problem:

Adding every field exposed by an Integration to an Asset Type.

This makes Asset Types difficult to understand and maintain.

Use only the information needed by INTERA users and business logic.

---

Mixing Business Concepts

Avoid Asset Types such as:

Customer / Contract / Billing Account

if these are separate business concepts with different meanings.

Model distinct concepts separately where appropriate.

---

A Simple Modelling Decision Guide

When deciding whether something should become an Asset, ask:

1. Is it a recognizable business object?

If yes, it may be suitable as an Asset.

2. Is it important to users?

Assets should represent objects that matter in Dashboards, Metrics, or workflows.

3. Will several Metrics describe it?

If yes, an Asset is often useful.

4. Will it appear in several Dashboards or Roles?

If yes, a shared Asset provides consistency.

5. Can information about it come from Integrations?

If yes, that information can contribute to the Asset model.

6. Does it need relationships to other business objects?

If yes, modelling it as an Asset may make those relationships easier to represent.

---

Recommended Modelling Process

When creating a new business model in INTERA:

1. identify the important business objects;
2. define one Asset Type for each distinct concept;
3. define only useful descriptive fields;
4. identify which information may be supplied by Integrations;
5. decide which values are fields and which are Metrics;
6. define relationships where useful;
7. test the model with a small number of Assets;
8. attach relevant Metrics;
9. display the Assets on a Dashboard;
10. expand the model gradually.

---

Recommended First Asset

For the first Asset, choose something:

• familiar;
• easy to identify;
• useful to a real user;
• associated with at least one useful Metric.

For example:

Asset Type:
Customer

Asset:
ACME Ltd

Fields:
Customer Code
Segment

Metric:
Outstanding Balance

or:

Asset Type:
Vessel

Asset:
MV Example

Fields:
IMO Number
Fleet

Metric:
VSAT Status

Once the model works correctly, expand it gradually.

---

Best Practices

Model the Business, Not the Software

Create business concepts such as:

• Customer;
• Vessel;
• Product;
• Supplier.

Keep the Asset model understandable to users.

---

Keep Asset Types Small

Add only fields that have a clear purpose.

A smaller model is easier to understand and maintain.

---

Put Measurable Operational Values in Metrics

Use Metrics for values that need:

• history;
• trend;
• synchronization;
• thresholds;
• health calculations.

---

Use Clear Business Identifiers

Where possible, use stable and recognizable identifiers to help administrators distinguish Assets correctly.

---

Use Integrations as Information Sources

Integrations can provide information used by Assets and Metrics.

The Asset model should remain focused on the business meaning of that information.

---

Preserve Useful History

Deactivate Assets rather than deleting them when historical context matters.

---