The Administration section explains how to configure and maintain an INTERA system after installation.

INTERA administrators are responsible for the system structure, connected data, users, access, synchronization, and operational configuration.

The exact options available may depend on the current INTERA version, installed Integrations, and enabled Role Packages.

Who Is an INTERA Administrator? #

An INTERA administrator is a user with permission to configure the system.

Administrators may be responsible for:

• initial system setup;
• company settings;
• users and Roles;
• Dashboard access;
• Integrations and Integration Instances;
• DataSources;
• Asset Types and Assets;
• Metric definitions;
• synchronization schedules;
• error monitoring;
• backup and maintenance;
• system upgrades.

In smaller installations, one person may perform all administrative tasks.

In larger installations, responsibilities may be divided between:

• a system administrator;
• an integration administrator;
• a business configuration administrator;
• a Dashboard editor;
• an IT support team.

Administrative access should be granted only to users who need it.

Open Administration Settings #

To open the administration area:

1. Sign in with an administrator account.
2. Open Settings.
3. Select the required configuration section.

Depending on your permissions and INTERA version, Settings may include:

• General Settings;
• Users;
• Roles;
• Integrations;
• Asset Types;
• Assets;
• Metrics;
• Dashboards;
• synchronization;
• system status;
• backup and restore;
• licensing or entitlement information.

Some advanced configuration may be available only through YAML or developer tools.

General Settings #

General Settings control the basic identity and behaviour of the INTERA installation.

Review these settings after installation and before connecting production data.

Company Name #

Set the name of the company or organization using INTERA.

The company name may appear in:

• the application header;
• Dashboards;
• reports;
• notifications;
• exports;
• administration pages.

Use the official company or business-unit name that users will recognize.

Timezone #

Set the correct system timezone.

Timezone configuration affects:

• synchronization schedules;
• Metric timestamps;
• date filters;
• Dashboard values;
• historical data;
• overdue calculations;
• daily and monthly periods.

An incorrect timezone can cause data to appear delayed, duplicated, or assigned to the wrong date.

The INTERA timezone should normally match the main operational timezone of the company or installation.

If the company operates in several countries, individual Integrations and Role Packages may require additional time-context rules.

Default Language #

Select the default interface language where multiple languages are supported.

The default language may affect:

• menus;
• system labels;
• validation messages;
• standard Dashboard text;
• date and number formatting.

Role Packages and custom Dashboards may contain their own translated labels.

Default Currency #

Set the main currency used by the company.

The default currency may be used when:

• creating currency Metrics;
• formatting Dashboard values;
• defining thresholds;
• displaying financial totals.

A Metric can still use a different currency when explicitly configured.

Do not combine values from different currencies unless a conversion rule has been defined.

Date and Number Formats #

Where available, configure the preferred formats for:

• dates;
• time;
• decimal separators;
• thousands separators;
• percentages;
• currency values.

Consistent formatting makes Dashboards easier to read and reduces interpretation errors.

Administrator Accounts #

The first administrator account is normally created during initial setup.

After the system is running, create separate accounts for other administrators instead of sharing one account.

Recommended Account Practice #

Use individual administrator accounts so that actions can be traced to a specific person.

Avoid:

• shared administrator usernames;
• weak passwords;
• using an administrator account for normal daily Dashboard viewing;
• granting full access to every user.

Where possible, keep:

• one protected primary administrator account;
• individual accounts for regular administration;
• separate standard accounts for daily use.

---

Change an Administrator Password #

To change a password:

1. Open the user profile or Settings → Users.
2. Select the administrator account.
3. Choose the password-change option.
4. Enter and confirm the new password.
5. Save the changes.

Use a unique password that is not reused in other systems.

If centralized authentication is supported in your deployment, follow your company identity-management policy.

Disable an Administrator Account #

Disable an account when:

• the user leaves the company;
• administrative responsibility changes;
• the account is no longer required;
• suspicious activity is detected.

Disabling is usually preferable to deleting because it preserves historical ownership and audit information.

Before disabling the only working administrator account, confirm that another administrator can sign in successfully.

Users #

Users are people who can sign in to INTERA.

A user account may contain:

• full name;
• username;
• email address;
• password or authentication method;
• assigned Roles;
• status;
• language preference;
• administrative permissions.

Create a User #

To create a user:

1. Go to Settings → Users.
2. Select New or Create User.
3. Enter the user’s name.
4. Enter the username or email address.
5. Set the authentication details.
6. Assign one or more Roles.
7. Save the user.

After saving, confirm that the user can sign in and see the correct Dashboards.

Assign Roles to a User #

Roles control which Dashboards and operational views a user can access.

To assign a Role:

1. Open the user record.
2. Find the Roles section.
3. Select the required Role or Roles.
4. Save the changes.

A user may have more than one Role.

For example, one person may be assigned:

• Finance Manager;
• Billing Operations Manager;
• Management Overview.

The user will receive access associated with all assigned Roles.

---

Disable a User #

Disable a user when access is no longer required.

A disabled user should not be able to sign in, but the account may remain visible for historical and audit purposes.

Common reasons include:

• employee departure;
• temporary suspension;
• change of responsibilities;
• testing-account cleanup.

Delete a User #

Delete a user only when you are certain the account and its history are no longer required.

In most production systems, disabling is safer than deletion.

Deletion may affect:

• ownership records;
• audit logs;
• manual Metric entries;
• configuration history.

Roles #

A Role represents a user responsibility or operational function.

Examples include:

• Finance Manager;
• Service Assurance Manager;
• Billing Operations Manager;
• Network Operations Manager;
• Fleet Manager;
• Procurement Manager;
• Customer Operations Manager.

Roles are used primarily for access control and Dashboard assignment.

Create a Role #

To create a Role:

1. Go to Settings → Roles.
2. Select New.
3. Enter a clear Role name.
4. Add a description.
5. Assign the required Dashboards.
6. Save the Role.

Use business-responsibility names rather than personal names.

Good examples:

• Revenue Assurance Manager;
• Technical Superintendent;
• Customer Support Supervisor.

Avoid:

• John’s Dashboard;
• Office User;
• General Access;
• Test Role 2.

Assign Dashboards to a Role #

A Dashboard can be assigned to one or more Roles.

To assign access:

1. Open the Role or Dashboard settings.
2. Select the relevant Dashboard.
3. Save the changes.
4. Test access using a user assigned to that Role.

A user should see only the information required for their responsibilities.

Role Design Guidelines #

Keep Roles understandable and stable.

A Role should represent a business function, not a temporary task.

Use separate Roles when:

• different users need different Dashboards;
• data visibility must be restricted;
• responsibilities are clearly different;
• a Role Package defines a specific operational function.

Avoid creating a new Role for every individual user unless there is a real access requirement.

Dashboard Administration #

Administrators control which Dashboards exist and who can access them.

Dashboard design is covered in detail in the Dashboards chapter.

From an administrative perspective, the main responsibilities are:

• create or import Dashboards;
• assign Dashboards to Roles;
• control publication status;
• verify Widget data;
• review navigation;
• maintain consistency;
• remove outdated Dashboards.

Dashboard Naming #

Use names that clearly describe the business purpose.

Good examples:

• Finance Overview;
• Billing Operations;
• Service Assurance;
• Fleet Performance;
• Supplier Control.

Avoid technical source-system names unless the Dashboard is specifically intended for technical users.

For example, Finance Overview is usually clearer than SQL Finance Query Dashboard.

Draft and Published Dashboards #

Where supported, use a draft state while editing a Dashboard.

Before publishing:

• verify all Widgets;
• confirm Metric values;
• test page navigation;
• check Role access;
• review mobile and desktop layouts;
• remove temporary labels;
• confirm that no test data remains.

Remove an Outdated Dashboard #

Before removing a Dashboard:

1. Check which Roles use it.
2. Confirm that no users depend on it.
3. Replace important information elsewhere.
4. Archive or export the configuration where possible.
5. Remove or disable the Dashboard.

Avoid deleting active Dashboards without reviewing dependencies.

Integration Administration #

Integrations connect INTERA to external systems.

Detailed setup is covered in the Integrations and Data chapter.

Administrators are responsible for:

• installing or enabling Integrations;
• creating Integration Instances;
• entering credentials;
• setting connection parameters;
• testing connectivity;
• reviewing DataSources;
• scheduling synchronization;
• monitoring errors.

Review Integration Status #

Open Settings → Integrations to review installed Integration Instances.

Check:

• connection status;
• last successful synchronization;
• last attempted synchronization;
• error messages;
• enabled or disabled state;
• synchronization schedule.

A connected Integration does not necessarily mean every DataSource is working correctly.

Review both the Integration Instance and the individual data operations that depend on it.

Enable or Disable an Integration Instance #

Disable an Integration Instance when:

• the external system is temporarily unavailable;
• credentials are being changed;
• the connection is no longer required;
• testing is in progress;
• repeated failures could create unnecessary load.

Disabling an Integration may cause related Assets and Metrics to become delayed or invalid.

Before disabling it, check which configurations depend on it.

Update Credentials #

External-system credentials may expire or be changed by company policy.

To update credentials:

1. Open the Integration Instance.
2. Edit the authentication settings.
3. Save the new credentials.
4. Test the connection.
5. Run a test synchronization.
6. confirm that dependent Metrics update successfully.

Do not store credentials in Dashboard YAML or visible text fields.

Synchronization Administration #

Synchronization updates INTERA using data from connected systems.

Each Integration or Metric may have its own synchronization settings.

Synchronization Schedule #

A synchronization schedule defines how often data is refreshed.

Examples include:

• every 15 minutes;
• hourly;
• daily;
• once per billing cycle;
• manually;
• according to the Integration default.

Choose a frequency appropriate for the business need.

A Metric used for live operations may require frequent updates.

A monthly financial Metric may need only daily or period-based synchronization.

More frequent synchronization is not always better. It may increase:

• load on the external system;
• API usage;
• processing time;
• data volume;
• error frequency.

Run Synchronization Manually #

Use manual synchronization when:

• testing a new Integration;
• checking a changed filter;
• validating credentials;
• updating a time-sensitive Dashboard;
• troubleshooting an error.

After manual synchronization, review:

• completion status;
• returned values;
• timestamps;
• error messages;
• dependent Metrics.

Last Update Time #

Assets and Metrics may display a last-update timestamp.

Use this timestamp to determine whether data is current.

A value may be technically valid but operationally outdated.

For example:

• yesterday’s balance may be unacceptable for a live collections Dashboard;
• last month’s revenue may be correct for a closed financial period;
• a vessel position from several hours ago may be delayed.

Freshness requirements depend on the Metric and business context.

Synchronization Status #

INTERA may show statuses such as:

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

The exact labels and icons may vary by version.

Valid #

The latest synchronization completed successfully and the value is considered usable.

Synchronization Error #

The most recent update failed, but the previous value may still exist.

Check the error message and Integration status.

Permanent Error #

The configuration cannot currently update.

Possible causes include:

• deleted Integration;
• unsupported DataSource;
• invalid field;
• permanently rejected credentials;
• removed external object.

Delayed #

The value has not been updated within the expected time.

The external system may still be connected, but the data is older than the allowed freshness limit.

Disabled #

The Integration, Metric, or synchronization rule has been intentionally turned off.

Error Monitoring #

Administrators should review system errors regularly.

A Dashboard may continue showing an old value after synchronization fails, so the visible number alone is not always enough.

Check:

• system status;
• Integration errors;
• Metric status;
• synchronization logs;
• delayed data;
• permanently invalid mappings.

Common Administration Errors #

Typical problems include:

• expired credentials;
• incorrect server address;
• external API unavailable;
• firewall or network restriction;
• missing field mapping;
• invalid DataSource filter;
• unsupported date period;
• external record deleted;
• changed external schema;
• permission denied;
• synchronization timeout.

Basic Troubleshooting Sequence #

When a synchronized value is wrong or missing:

1. Check the Metric status.
2. Check the last-update time.
3. Check the Integration Instance.
4. Test the connection.
5. Review the selected DataSource.
6. Review filters and time period.
7. Confirm that the external field still exists.
8. Run synchronization manually.
9. Compare the result with the source system.
10. Review logs or contact the Integration developer if required.

Do not immediately change several settings at once.

Change one item, test it, and record the result.

Asset Type Administration #

Asset Types define the structure of business objects stored in INTERA.

Administrators may create, edit, or disable Asset Types.

Detailed modelling guidance is covered in the Assets and Data Modelling chapter.

Review Before Editing an Asset Type #

Changing an Asset Type may affect:

• existing Assets;
• Widgets;
• Metric links;
• Integration mappings;
• Role Packages;
• YAML definitions.

Before changing a field:

1. Check where it is used.
2. Confirm whether the change is compatible.
3. Back up the configuration where possible.
4. Test the change with sample data.
5. Verify affected Dashboards.

Renaming or deleting a field may break dependent configuration.

Disable Instead of Delete #

If an Asset Type is no longer needed, disabling or archiving it is usually safer than deleting it.

Deletion may affect historical data and references.

Metric Administration #

Metrics may be manual, synchronized, calculated, or composite.

Administrators are responsible for ensuring that each Metric has:

• a clear name;
• the correct value type;
• a valid data source;
• appropriate filters;
• an explicit time period;
• a suitable synchronization schedule;
• correct thresholds;
• correct access and presentation.

Detailed Metric creation is covered in the Metrics chapter.

Validate Metric Results #

After creating or editing a Metric:

1. Run synchronization.
2. Compare the result with the source system.
3. Test the selected period.
4. Check aggregation logic.
5. Check threshold behaviour.
6. Confirm the display format.
7. Verify the Dashboard Widget.
8. Review historical values where applicable.

Never assume that a successful synchronization means the business logic is correct.

A query can run successfully and still return the wrong result.

Manual Metrics #

Some Metrics may be updated manually.

Examples include:

• commission paid status;
• approval state;
• readiness flag;
• manually confirmed risk level.

Administrators should define:

• who can enter the value;
• which values are allowed;
• whether comments are required;
• whether history is retained;
• when the value becomes outdated.

Role Package Administration #

A Role Package provides predefined configuration for a business function or industry.

A package may include:

• Roles;
• Dashboards;
• Asset Types;
• Metrics;
• thresholds;
• mappings;
• Integration requirements.

nstall or Enable a Role Package #

When enabling a Role Package:

1. Review the package description.
2. Check required Integrations.
3. Check required DataSources.
4. review included Roles.
5. review included Dashboards.
6. map package fields to external data.
7. configure periods and thresholds.
8. test all Metrics.
9. assign users.
10. publish the Dashboards.

A package is a starting structure, not a guarantee that all data will work without configuration.

Update a Role Package #

Before updating a package:

• review release notes;
• check for changed Metrics;
• check for renamed fields;
• check Dashboard changes;
• export or back up custom configuration;
• test in a non-production environment where possible.

Custom changes may conflict with package updates.

Backup and Restore #

Backups protect INTERA configuration and stored data.

The exact backup method depends on the deployment.

A backup may include:

• system configuration;
• users and Roles;
• Dashboard YAML;
• Asset Types;
• Assets;
• Metric definitions;
• Metric history;
• Integration settings;
• package configuration;
• database content.

Credentials may require separate secure handling.

Backup Recommendations #

Create backups:

• before an upgrade;
• before major configuration changes;
• before changing Asset Types;
• before installing or updating Role Packages;
• before database maintenance;
• according to the company backup policy.

Store backups outside the INTERA server where possible.

A backup on the same failed disk is not sufficient protection.

Test Restore Procedures #

A backup is useful only if it can be restored.

Periodically test:

• whether the backup file is readable;
• whether the database can be restored;
• whether configuration is complete;
• whether users can sign in;
• whether Integrations can be reconnected;
• whether Dashboards and Metrics work after restore.

Do not wait for a production failure to test the restore process.

Upgrades #

INTERA may receive updates that add features, fix errors, or change configuration behaviour.

Before upgrading:

1. Read the release notes.
2. Confirm version compatibility.
3. Back up the system.
4. Record the current version.
5. Check Integration compatibility.
6. Check Role Package compatibility.
7. schedule a suitable maintenance period.
8. Perform the upgrade.
9. Review logs.
10. Test critical functions.

Post-Upgrade Checks #

After an upgrade, verify:

• administrator login;
• user login;
• Integrations;
• synchronization;
• key Metrics;
• Dashboard rendering;
• role access;
• manual data entry;
• historical data;
• error logs.

Start with the most important operational Dashboard.

Security Recommendations #

INTERA may contain sensitive operational and financial information.

Administrators should follow basic security practices.

Limit Administrative Access #

Grant administrator permissions only where required.

Use Roles and normal user accounts for daily Dashboard access.

Protect Credentials #

Do not place passwords or API keys in:

• Dashboard text;
• visible YAML examples;
• screenshots;
• shared documentation;
• email messages;
• support tickets without secure handling.

Use the dedicated Integration credential fields.

Use Secure Network Access #

Production INTERA systems should be protected using the company’s normal security controls.

These may include:

• HTTPS;
• firewall rules;
• VPN;
• restricted administrative networks;
• reverse proxy;
• identity provider;
• access logs.

Installation and network-security details are covered in the Installation chapter and deployment documentation.

Remove Unused Accounts and Connections #

Regularly review:

• inactive users;
• former employees;
• unused administrator accounts;
• disabled Integrations;
• obsolete API credentials;
• old testing connections;
• unused Dashboards.

Reducing unused access reduces security and maintenance risk.

Routine Administration Checklist #

The following checklist can be used as a basic maintenance routine.

Daily or Operational Review #

For systems used in daily operations:

• review Integration errors;
• review delayed Metrics;
• check critical Dashboards;
• confirm recent synchronization;
• investigate permanent errors.

Weekly Review #

• review disabled or failing Integrations;
• check user access changes;
• review important Metric results;
• verify manual Metrics;
• review system logs;
• check available storage.

Monthly Review #

• review administrator accounts;
• review inactive users;
• review Role assignments;
• test backups;
• review outdated Dashboards;
• review unused Integrations;
• confirm package and Integration versions;
• inspect long-running synchronization tasks.

Before Major Changes #

• create a backup;
• export important YAML;
• document current settings;
• identify dependencies;
• test the change;
• verify the result;
• prepare a rollback method.

Recommended Administration Approach #

Do not configure the entire company at once.

Use a controlled sequence:

1. connect one Integration;
2. validate one DataSource;
3. create one Asset or Metric;
4. display it on one Dashboard;
5. assign one Role;
6. confirm synchronization;
7. expand gradually.

This makes errors easier to identify and reduces the risk of building large amounts of configuration on incorrect assumptions.

The administrator’s main responsibility is not simply to make INTERA display data.

It is to ensure that the displayed information is current, correctly modelled, understandable, and available to the right users.