FAQs

OPUS Reports and Dashboards (ORD) is a no-code reporting and visualization capability on the OPUS Platform. It presents supply chain transaction data in a clear, structured format to support informed decision-making.

ORD consolidates data from multiple partners and systems in a multienterprise supply chain. It organizes transactions such as purchase orders, acknowledgements, deliveries, inventory balances, and compliance data into consistent reports and dashboards.

ORD is designed for business users and does not require technical skills or coding experience. Reports and dashboards are built using a drag-and-drop interface that updates in real time, allowing users to preview how data will be presented.

The ORD framework includes business objects, query objects, reports, and dashboards. These components work together to retrieve, structure, and visualize supply chain data.

Business objects represent the underlying data, such as transactions and records. Query objects combine these business objects and define how the data is related and retrieved. Reports use query objects to structure and present the data for analysis. Dashboards bring together one or more reports to provide a consolidated, visual view of performance.

The same flow applies across all use cases, progressing from business objects to query objects to reports to dashboards.

Business objects represent the transactions to analyze, such as purchase orders, acknowledgements, deliveries, inventory balances, or compliance records. Selecting data to view means identifying the relevant business objects.

The ORD Marketplace provides pre-configured query objects, reports, and dashboards for common business use cases. These items help accelerate report and dashboard creation by offering reusable, ready-to-use analytics.

Marketplace items are read-only and cannot be edited directly. To modify a Marketplace query object, report, or dashboard, create a copy in the Company catalog. The copied item opens in the Edit state, where relationships, filters, fields, and visualizations can be updated as needed.

Marketplace items can be copied at all levels, including query objects, reports, and dashboards. This approach supports reuse of validated logic while allowing customization for specific business requirements.

ORD supports different personas with distinct responsibilities in creating and using analytics.

• TraceLink Administrator creates and manages query objects, reports, and dashboards. This persona defines reusable analytics and ensures that data is consistent and aligned with business needs.

• Business User uses reports and dashboards to support day-to-day decisions. This persona focuses on analyzing data, identifying issues, and taking action.

• Partners access shared reports and dashboards. This shared visibility enables collaboration and helps resolve issues across the network.

These personas work together to ensure that the right information is available to the right users while maintaining consistency and control.

ORD includes three elements: Query Objects, Reports, and Dashboards. These elements are connected and follow the same lifecycle and rules.

Each element starts in the Edit state, where it is configured. This includes defining relationships, criteria, fields, and visualizations. When the element is ready for use, it is moved to the Released state.

There are two key dependencies to keep in mind:

• A Query Object must be released before it can be used to create a Report.

• A Report must be released before it can be used in a Dashboard.

These rules ensure that all downstream elements rely on stable and approved data structures.

Once an element is released, it cannot be edited directly. This helps maintain consistency for users who rely on existing Reports and Dashboards.

To make changes, create a copy or a new version of the element and apply updates there. The updated element starts in the Edit state and can be released after validation.

Use the available actions based on the need:

• Use Copy to duplicate an existing element. The copied element opens in the Edit state.

• Use New Version to update an existing released element while preserving the original.

• Use New to create an element from scratch.

A query object defines how data is retrieved and how business objects relate to each other in ORD. It serves as the foundation for reports and dashboards.

Each query object includes one primary object, which represents the main business object to analyze (e.g. purchase order, delivery, or T2 record). Related business objects can be added as secondary, tertiary, or quaternary objects to provide additional context.

Relationships between these objects define how ORD combines data. A well-designed query object can be reused across multiple reports, ensuring consistency and reducing the need to rebuild logic.

Reports are always built on a query object, which determines the available data and attributes for analysis.

Query objects are created and managed by Report Builder Creator. They define the data structure used in reports and dashboards.

A Report User does not interact with query objects directly. This role works with reports and dashboards built on top of them, which simplifies the reporting experience while maintaining control over the underlying data structure.

Object relationships define how data from different business objects is connected in a query object. They allow multiple transactions to be combined into a single dataset for reporting.

These relationships are based on predefined configurations that determine how objects can be linked through matching fields.

A query object starts with a primary business object. Additional objects (secondary, tertiary, quaternary) are linked through relationships to bring in related data.

Each relationship connects two objects using fields that store related values. When the values in these fields match, ORD combines the data from both objects into a single result.

The relationship section includes the following fields:

• From Object – The source object. For a secondary object, the primary object acts as the source. For a tertiary object, the secondary object acts as the source.

• From Attribute – The field in the source object that acts as the connection point.

• Direction – Indicates how the relationship is defined between objects. The available options are INCOMING and OUTGOING. These are ORD concepts based on how objects reference each other through their fields.

• To Object – The related object that is being added to the query object.

• To Attribute – The field in the related object that matches the source field.

These fields work together to define how data is joined between objects.

To define a relationship, identify how the two objects reference each other through their fields.

For example, consider:

• Purchase Order (PO)

• Purchase Order Acknowledgement (PO ACK)

A Purchase Order has an Order Number. A related Purchase Order Acknowledgement may store this value as a Reference Order Number.

Relationship example (OUTGOING):

• From Object: Purchase Order

• From Attribute: Order Number

• Direction: OUTGOING

• To Object: Purchase Order Acknowledgement

• To Attribute: Reference Order Number

In this case, the relationship is defined as OUTGOING from the Purchase Order to the Purchase Order Acknowledgement.

Relationship example (INCOMING):

• From Object: Purchase Order

• From Attribute: Order Number

• Direction: INCOMING

• To Object: Purchase Order Acknowledgement

• To Attribute: Reference Order Number

In this case, the relationship is defined as INCOMING to the Purchase Order from the Purchase Order Acknowledgement.

If both fields contain the same value (e.g. 12345), ORD links the records and displays them together in the report.

The direction depends on how the relationship is defined between the two objects. Select the relationship option where the fields clearly represent the same reference value across both objects.

Select attributes that correctly match data between objects to ensure accurate results. It is recommended to use base-level fields and confirm whether the data is at the transaction level or item level.

Add only the required related objects. Each additional relationship increases complexity and can impact performance.

Review relationships before releasing the query object, as changes cannot be made after it is released.

A report presents data from a single query object in a structured, interactive table. It supports analysis and decision-making within the ORD framework.

A report is always based on one query object, which defines the available business objects and fields. The report controls how that data is displayed and how it can be analyzed.

Reports are no-code and interactive. Data can be filtered, sorted, grouped, pivoted, or rearranged directly in the table. Computed fields can be added to perform simple calculations and support trend analysis.

Reports are used to analyze data retrieved from a query object. They allow users to apply criteria such as process network, partners, date ranges, and columns to focus on relevant data.

A report can be reused across multiple dashboards. This ensures consistency, as different users and teams rely on the same data and definitions.

Column Mapper is used to control how list-based or repeated data is displayed in reports. It helps ensure that only related values from different lists are shown together.

In some reports, data from multiple lists can be combined in a way that produces extra or unrelated rows. This happens when values are displayed without considering whether they are actually related.

Column Mapper addresses this by allowing related columns to be grouped into mapping sets. Each mapping set includes two or more columns that should be treated as connected. Only columns already selected in the report can be used for mapping.

When Column Mapper is configured, the report displays only rows where the selected columns contain matching values. This reduces unnecessary rows and ensures that related data appears together. If no Column Mapper is configured, the report continues to display data as usual.

For example, when a report includes order information and item details stored in lists, Column Mapper can be used to associate the order number with its corresponding items. Only items with matching order numbers are displayed, while unrelated items are excluded.

Drill-down allows navigation from a report to the underlying business object records. It helps move from summarized data in a report to detailed transaction-level information.

When viewing a report, a row can be selected to access related business objects. The available options are based on the objects included in the query object and may include primary, secondary, tertiary, or quaternary business objects.

These options appear in the format Go to [Name of Business Object]. Selecting an option opens the corresponding business object in a new tab, enabling direct access to the source data for further analysis.

Drill-down is available in both Edit and Released states and supports navigation across solutions.

The Limit Rows filter is used to restrict the number of records displayed in a report based on the applied sorting and grouping. It helps focus on the most relevant records, such as the most recent or highest-priority entries.

In reports with multiple records for the same identifier, standard filters may still return large datasets. The Limit Rows filter refines the results by displaying only a subset of records after all filters, grouping, and sorting have been applied.

This filter can be used to view the most recent or least recent records, either across the entire report or within grouped data. It is particularly useful for transactional data where only the latest or most relevant entries are required for analysis.

By reducing the number of displayed rows, the Limit Rows filter helps minimize report clutter and improves readability and decision-making.

A dashboard is the top layer of the ORD framework. It brings data together on a single page and presents it through tables and charts to support high-level analysis.

Dashboards are built on reports. Each dashboard element uses one or more reports as its data source. Reports can be reused across multiple dashboard elements or dashboards, ensuring consistency in metrics and definitions.

Dashboards support interactive data exploration. Once data loads, users can apply filters, change chart types, and adjust how information is displayed.

Filters apply across linked elements, ensuring a consistent view of the data.

Dashboards also support cross-network and cross-application visibility. Data from different process networks and applications can be combined to monitor trends, identify risks, and focus on key areas.

TraceLink apps are extended through solutions, which pull together assets that define how the app looks and functions when users interact with it (i.e. the app's data model, pages workflows, roles, and policies). Solutions available in the Marketplace Catalog can be saved as Company Solutions and configured to meet a company's specific use cases and business needs. For more information on solutions and configuring solutions for an app, see the OPUS Solution Environment Help Center.

OPUS Reports and Dashboards (ORD) solution is available for Report Builder.

The roles available to OPUS users are determined by the solutions applied to the apps and networks available to the user. The following roles are available to all users of the OPUS Platform:

• Report Builder Creator – Allows users to create, configure, and manage query objects, reports, and dashboards.
• Report User – Allows users to create, configure, and manage reports and dashboards.

Users' access to reports and dashboards in a solution is determined by their role in the solution, not their Report Builder role.

Roles group a set of permissions for specific actions (either in the UI or via API), side menu items, and data within an app. The solution applied to the app or its network determines which roles are available. Administrators assign users to roles when they assign users to an app, its network, or its Links.

Owners assign specific roles to Links, allowing their Partners to assign those roles to the Partner users with access to the Link.

Companies must own OPUS Solution Environment (OSE) to add or edit roles. If your company owns OSE and you also have the Solution Designer role assigned, you can add new roles to a Company Solution or edit existing roles by navigating to OSE and selecting Roles in the side menu. See the OPUS Solution Environment Help Center for more information. If your company does not own OSE, then contact TraceLink Support for more information.

Passwords must be a minimum of 8 characters, must not be your email, and must include at least one:

• Numerical digit
• Lowercase letter
• Uppercase letter
• Special character

If your company was enabled on the OPUS Platform from Track & Trace Services, the following password settings from Track & Trace Services apply:

• Number of previous passwords that cannot be reused.
• Number of login attempts allowed before the account is locked.
• Number of days until the password expires.

If your company was not originally enabled on Track & Trace Services, the following default settings apply to TraceLink SSO:

• The previous 6 passwords cannot be reused.
• 5 login attempts are allowed before the account is locked.
• Passwords expire in 30 days.