Asset Types

Asset Types define the business objects that INTERA monitors.

Examples include customers, vessels, products, suppliers, bank accounts, vehicles, contracts, services, and network nodes.

An Asset Type describes the structure of an Asset: what it represents, which fields it contains, and which Metrics may be associated with it.

Individual Assets are created from an Asset Type.

For example:

• Vessel is an Asset Type;
• MV Northern Star is an Asset;
• Current Position, Fuel Consumption, and Open Technical Issues are Metrics linked to that Asset.

A well-designed Asset Type gives dashboards, Metrics, scripts, and reconciliation rules a clear and consistent business context.

Asset Types from Role Packages #

Most Asset Types are supplied by Role packages.

A Role package may include:

• Asset Type definitions;
• required and optional fields;
• Metrics associated with each Asset Type;
• dashboards and widgets;
• reconciliation rules;
• scripts and triggers;
• recommended naming and display settings.

For example, a Fleet Management Role package may include Asset Types such as:

• Vessel;
• Fleet;
• Port;
• Supplier;
• Technical Component.

A Revenue Assurance Role package may include:

• Product;
• Customer Segment;
• Provider;
• Service;
• Billing Account.

Using the Asset Types supplied by a Role package is normally the fastest and safest way to begin. These Asset Types are designed to work with the package’s dashboards, Metrics, rules, and integrations.

Before creating a custom Asset Type, check whether an appropriate type already exists in an installed Role package.

When to Create a Custom Asset Type #

Create a custom Asset Type when your organisation needs to monitor a business object that is not already represented by an installed package.

A custom Asset Type may be useful when:

• your organisation uses a specialised operational object;
• an existing Asset Type is too broad;
• a package does not include a required object;
• you need additional structure for custom dashboards or rules;
• the object has its own identity, fields, Metrics, and lifecycle.

Examples of valid custom Asset Types include:

• Satellite Terminal;
• Warehouse;
• Service Contract;
• Customer Project;
• Production Line;
• Network Gateway;
• Insurance Policy.

Do not create a new Asset Type only because you need one additional value. In many cases, the value should be added as a field or Metric to an existing Asset Type.

Create a Custom Asset Type #

To create a custom Asset Type:

1. Open Settings.
2. Select Asset Types.
3. Click Create Asset Type.
4. Enter the name and description.
5. Define the Asset Type fields.
6. Configure identification and display options.
7. Link relevant Metrics.
8. Save the Asset Type.

The exact options available may depend on your permissions and installed INTERA packages.

Name and Description #

Every Asset Type should have a clear name and a short description.

The name should identify the kind of business object represented by the Asset Type.

Good examples:

• Vessel
• Customer
• Bank Account
• Service Contract
• Network Node
• Product

Avoid names that describe a screen, report, process, or collection of unrelated data.

Poor examples:

• Finance Dashboard Data
• Monthly Report
• Important Things
• General Information
• Billing Results
• Operational Data

The description should explain what one Asset of this type represents.

For example:

Represents an individual customer contract that may be linked to billing, CRM, and accounting systems.

A clear description is especially important when several similar Asset Types exist.

Asset Type Identifier #

Each Asset Type has an internal identifier.

The identifier is used in configuration files, integrations, scripts, and package definitions.

For example:

service_contract

The identifier should normally:

• use lowercase letters;
• use underscores between words;
• remain stable after the Asset Type is created;
• avoid spaces and special characters;
• be unique within the INTERA environment.

Changing an identifier after the Asset Type is already in use may break dashboards, mappings, scripts, and rules.

The display name may be changed later without changing the identifier.

Defining Fields #

Fields store descriptive or identifying information about an Asset.

For a Vessel Asset Type, fields may include:

• Vessel Name;
• IMO Number;
• Flag;
• Fleet;
• Technical Manager;
• Operational Status.

For a Customer Asset Type, fields may include:

• Customer Name;
• Customer Number;
• Country;
• Account Manager;
• Customer Segment;
• Current Status.

Fields should describe the Asset itself.

Use fields for information that is relatively stable or that forms part of the Asset’s identity and classification.

Use Metrics for measured, calculated, time-sensitive, or historical values.

For example:

Information	Recommended Definition
Vessel name	Field
IMO number	Field
Current vessel position	Metric
Customer segment	Field
Outstanding balance	Metric
Contract number	Field
Monthly revenue	Metric
Service status	Field or Metric, depending on use

A service status may be a field when it is treated as a current descriptive property. It may be a Metric when changes, timestamps, thresholds, and history are important.

Field Properties #

When defining a field, configure the following properties where applicable.

Field Name #

The name shown to users.

Examples:

• Customer Number
• Contract Start Date
• Assigned Manager
• Service Category

Field Identifier #

The stable internal name used in configuration.

Examples:

customer_number
contract_start_date
assigned_manager
service_category

Data Type #

The type of value stored in the field.

Common data types include:

• text;
• number;
• date;
• date and time;
• boolean;
• status;
• reference;
• URL;
• email address;
• coordinates.

The selected data type determines validation, formatting, and editing behaviour.

Required #

A required field must contain a value before the Asset is considered complete.

Only make a field required when every Asset of this type is expected to have that information.

For example, a vessel may always require a vessel name, but a satellite terminal serial number may be optional during initial import.

Unique #

A unique field cannot contain the same value for two Assets of the same type.

Examples of suitable unique fields include:

• IMO number;
• customer number;
• contract identifier;
• terminal serial number;
• external account ID.

Do not mark a field as unique unless the external business process guarantees uniqueness.

Searchable #

Searchable fields can be used to locate Assets.

Names, identifiers, serial numbers, and account numbers are normally good searchable fields.

Display Field #

The display field is the main value used to identify an Asset in lists, dashboards, and selection controls.

For example:

• Vessel Name for Vessel;
• Customer Name for Customer;
• Account Name for Bank Account;
• Product Name for Product.

An Asset Type should normally have one clear display field.

Default Value #

A default value is assigned when a new Asset is created and no other value is supplied.

Use defaults carefully. An incorrect default can make incomplete Assets appear valid.

Allowed Values #

Status and category fields may use a fixed list of allowed values.

For example, a Contract Status field may allow:

• Draft;
• Active;
• Suspended;
• Expired;
• Cancelled.

Controlled values improve consistency and make filtering more reliable.

Reference Fields #

A reference field links one Asset to another Asset.

For example:

• a Vessel may reference a Fleet;
• a Contract may reference a Customer;
• a Network Node may reference a Site;
• a Product may reference a Provider;
• a Vehicle may reference a Depot.

Use reference fields instead of repeating the same information as text.

For example, a Vessel Asset Type should reference a Fleet Asset rather than store the fleet name independently in every vessel record.

References make it possible to:

• navigate between related Assets;
• group Metrics by parent Asset;
• filter dashboards;
• reuse shared information;
• avoid inconsistent names.

Linking Metrics to Assets #

Metrics describe the measurable or changing state of an Asset.

A Metric may be linked to one or more Asset Types.

For example, the following Metrics may be linked to Vessel:

• Current Position;
• Fuel Consumption;
• Open Defects;
• Days Until Next Inspection;
• Communication Availability.

The following Metrics may be linked to Customer:

• Outstanding Balance;
• Monthly Revenue;
• Open Tickets;
• Average Payment Delay;
• Active Services.

To link a Metric to an Asset Type:

1. Open the Asset Type.
2. Select Metrics.
3. Click Add Metric.
4. Choose an existing Metric definition or create a new one.
5. Configure how the Metric applies to the Asset Type.
6. Save the changes.

The Metric definition controls the value type, source, calculation, status, and history.

The Asset Type provides the business context.

For example, Outstanding Balance is the Metric definition, while Customer: Acme Ltd identifies which Asset the value belongs to.

Shared Metrics #

The same Metric definition may apply to several Asset Types.

For example, Last Updated may apply to:

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

However, a Metric should only be shared when it has the same business meaning.

Do not reuse the same Metric definition only because two values have the same data type.

For example:

• Customer Outstanding Balance;
• Supplier Amount Due.

Both are currency values, but they represent different business concepts and should usually be separate Metrics.

Metric Display Names #

A Metric may have a general name and a Role-specific display name.

For example, the Metric identifier may be:

outstanding_amount

On different dashboards, it may appear as:

• Outstanding Balance;
• Customer Debt;
• Unpaid Amount;
• Receivables.

This allows Role packages and widgets to use clear terminology without changing the underlying Metric definition.

The Asset Type should be linked to the correct Metric definition, while the dashboard or Role package controls how the Metric is presented.

Naming Conventions #

Consistent naming makes Asset Types easier to understand and reuse.

Use Singular Names #

Asset Type names should normally be singular.

Good:

• Customer
• Vessel
• Product
• Supplier

Avoid:

• Customers
• Vessels
• Products List
• All Suppliers

The Asset Type represents one Asset, even when many Assets exist.

Use Business Terms #

Use words recognised by the people who work with the object.

For example, use Vessel rather than Floating Asset when the system is intended for shipmanagement users.

Use Customer rather than External Commercial Entity unless the broader term is genuinely required.

Avoid Technical Source Names #

Do not name an Asset Type after the table, API endpoint, or external application from which it is imported.

Poor examples:

• SAP_CUSTOMER_MASTER
• CRMAccountsTable
• API Vessel Object
• Billing Customer Record

The Asset Type should describe the business object, not its technical source.

An Asset may later be linked to several external systems.

void Role Names #

An Asset Type should describe an object, not the user who views it.

Poor examples:

• Finance Manager Customer
• NOC Service
• CEO Product
• Accountant Supplier

Role-specific presentation belongs in dashboards and Role packages.

Keep Names Stable #

Changing an Asset Type name may confuse users. Changing its internal identifier may also break configuration.

Choose a clear and durable name when the Asset Type is created.

Avoid Unnecessary Prefixes #

Poor examples:

• INTERA Customer
• Main Customer
• Business Vessel
• Company Product Asset

Use the simplest accurate name.

Prefixes may be appropriate only when they distinguish genuinely different concepts, such as:

• Retail Customer;
• Wholesale Customer;
• Internal Service;
• External Service.

Even in these cases, first consider whether one Asset Type with a category field would be better.

Good Asset Types #

A good Asset Type has the following characteristics:

• it represents one clear business object;
• individual Assets have a stable identity;
• it has useful fields;
• Metrics can meaningfully be linked to it;
• it may be referenced by other Assets;
• it remains valid independently of one dashboard or Integration;
• users understand what one Asset represents.

Good Example: Vessel #

A Vessel has:

• a unique identity;
• stable fields such as name and IMO number;
• relationships to fleet and manager;
• Metrics such as position, fuel use, and open defects;
• relevance across multiple dashboards and integrations.

Good Example: Service Contract #

A Service Contract has:

• a contract identifier;
• a linked customer;
• start and end dates;
• a service category;
• Metrics such as monthly value, usage, and payment status;
• a lifecycle that can be monitored.

Good Example: Network Node #

A Network Node has:

• a node name or identifier;
• a location;
• a technical type;
• a linked site or network;
• Metrics such as availability, traffic, latency, and alarm count.

Poor Asset Types #

A poor Asset Type usually represents a report, value, event, or temporary grouping instead of a business object.

Poor Example: Monthly Revenue #

Monthly Revenue is a Metric, not an Asset Type.

It is a measured value that should be linked to an Asset such as:

• Company;
• Product;
• Customer Segment;
• Department.

Poor Example: Overdue Customers #

Overdue Customers is a filtered group of Customer Assets, not a separate Asset Type.

Use:

• Asset Type: Customer;
• Metric: Outstanding Balance or Days Overdue;
• filter: overdue only.

Poor Example: Finance Dashboard #

A dashboard is a presentation layer, not a business object.

The dashboard may display Assets such as bank accounts, customers, suppliers, and contracts.

Poor Example: Billing Errors #

A billing error is normally an event, status, reconciliation result, or Metric.

It should not be an Asset Type unless each error has its own persistent identity and lifecycle that must be tracked as a separate business object.

Poor Example: Current Month #

A time period is not an Asset Type.

Time periods should be handled through Metric periods, synchronization filters, dashboard filters, or the package Time Context.

Poor Example: Data from System A #

An external system is an Integration, not an Asset Type.

The data should be mapped to business Asset Types such as Customer, Product, Invoice, or Service.

Asset Type or Field? #

Create a separate Asset Type when the item:

• has its own identity;
• has several fields;
• has Metrics of its own;
• is referenced by other Assets;
• needs to appear independently in dashboards or rules.

Use a field when the item:

• is a simple property of another Asset;
• does not need its own Metrics;
• does not have an independent lifecycle;
• is not referenced elsewhere.

For example, Country may be a text or reference field on Customer. It only needs to become a separate Asset Type when countries have their own properties, Metrics, mappings, or operational meaning in the environment.

Asset Type or Metric? #

Use an Asset Type for the object being monitored.

Use a Metric for a value describing that object.

Examples:

Asset Type	Metric
Bank Account	Current Balance
Customer	Outstanding Balance
Vessel	Current Position
Product	Monthly Sales
Network Node	Availability
Supplier	Amount Due
Contract	Days Until Expiry

A useful test is to form a sentence:

The Metric describes the Asset.

For example:

Monthly Sales describes the Product.

If the sentence makes sense, the distinction is probably correct.

Avoid Duplicating Asset Types #

Before creating a custom Asset Type, review existing package and custom definitions.

For example, creating all of the following may cause unnecessary duplication:

• Customer;
• Client;
• Account;
• Company Customer;
• Billing Customer.

These terms may represent the same underlying business object.

Duplicate Asset Types create problems with:

• Integration mapping;
• Metric definitions;
• dashboard filters;
• reconciliation rules;
• Asset matching;
• reporting consistency.

Create separate Asset Types only when the business distinction is real and important.

For example, Customer and Supplier may both represent companies, but their operational roles, Metrics, relationships, and rules are different enough to justify separate types.

Modifying Package Asset Types #

Asset Types supplied by Role packages may be protected from direct modification.

This prevents package updates from overwriting local changes or breaking package dashboards.

Depending on the package, you may be able to:

• add custom optional fields;
• link additional Metrics;
• change display settings;
• create a local extension;
• copy the Asset Type into a custom definition.

Avoid removing required fields or changing internal identifiers used by the package.

Before modifying a package Asset Type, review which dashboards, scripts, Metrics, and reconciliation rules depend on it.

Deleting an Asset Type #

An Asset Type should not be deleted while it is still in use.

Before deletion, check whether it is referenced by:

• existing Assets;
• Metrics;
• dashboards;
• integrations;
• field mappings;
• scripts;
• triggers;
• reconciliation rules;
• other Asset Types.

In most cases, disabling or archiving an unused Asset Type is safer than deleting it.

Deletion may permanently remove configuration or make historical data unavailable.

Recommended Design Process #

When creating a custom Asset Type:

1. Identify the real business object.
2. Confirm that an equivalent Asset Type does not already exist.
3. Choose a clear singular name.
4. Define a stable internal identifier.
5. Select the main display and unique fields.
6. Add only fields that describe the Asset.
7. Use references for relationships to other Assets.
8. Link Metrics that measure the Asset.
9. Test the Asset Type with a small number of sample Assets.
10. Review how it appears in dashboards, filters, and rules.

A small, clear Asset Type is normally better than a large generic type containing unrelated fields.