FAQs

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.

The OPUS Actions app extends OPUS app behavior by running custom JavaScript in response to supported OPUS events. An OPUS Action contains business logic that can automate tasks across apps, add or edit data, and invoke Agents.

OPUS Actions run when configured events occur, such as when an object is added or edited or a workflow transition completes. Users can bind Actions at the Solution, Process Network, or Agent level.

Users can save OPUS Actions to the Catalog as reusable OPUS Action Definitions. They can use these definitions to add new local OPUS Actions.

An OPUS Event represents an event in an OPUS app that can trigger an OPUS Action.

For example:

• An object is added.

• An object is updated.

• A workflow transition completes.

When adding an OPUS Action, select the OPUS Event that triggers the action.

An OPUS Action is executable JavaScript business logic that runs in response to a configured OPUS event.

An OPUS Action can include:

• Name and Description

• OPUS Event

• Binding Level (Solution, Process Network, or Agent)

• Environment Variables

• JavaScript code

• Integration Principal

• Activation state

OPUS Actions are local to the environment in which they are created.

An OPUS Catalog Action Definition is a reusable, versioned Catalog representation of an OPUS Action. Use Catalog Action Definitions when the same action logic needs to be reused in another environment.

When an OPUS Action is added from a Catalog Action Definition, OPUS creates a local copy. Changes to the Catalog Action Definition do not automatically update the local action, and changes to the local action do not modify the Catalog Action Definition.

OPUS Actions currently support the following event types:

• POST_OPERATION – Runs an action after an object operation completes successfully.

• POST_TRANSITION – Runs an action after a workflow transition completes successfully.

A binding determines the context in which an OPUS Action applies. Choose the binding level based on the context in which the OPUS Action must apply:

• Solution – Use when an action must apply to the selected Solution or Solutions.

• Process Network – Use when an action must apply only to selected Process Networks.

• Agent – Use when an action should apply based on the configured agent criteria.
  An Agent Binding does not automatically invoke an agent. To invoke an agent, the action JavaScript must explicitly call the Agent API.

No. An OPUS Action must be explicitly activated to execute when their configured Event occurs.

Yes. Multiple OPUS Actions can use the same event. Each action must independently match its configured binding.

An OPUS Action can be bound to a Solution, Process Network, or Agent, depending on where the automation should apply.

No. An agent binding determines when the action applies. To invoke an agent, the action JavaScript must explicitly call the Agent API.

Yes. Save tested Action logic to the Catalog as an OPUS Catalog Action Definition and use it to create local OPUS Actions.

No. An action created from an OPUS Catalog Action Definition is an independent local copy. Changes to the Catalog Action Definition do not automatically update existing local actions.

Keep each action focused on a clear business responsibility. Use environment variables for environment-specific configuration, select the appropriate binding level, handle API failures, use logging for development and troubleshooting, and thoroughly test actions before using them in production.

No. Use environment variables for environment-specific configuration instead of hardcoding values in the action.

Yes. Use logging during development and troubleshooting to inspect event payloads, verify binding context, trace calls to other apps, and diagnose failures. Avoid unnecessary diagnostic logging in production.

Test the selected event, bindings, environment-variable values, Integration Principal permissions, event payload assumptions, downstream API calls, and agent invocation, if applicable.

Check the response returned by downstream API calls and handle failures appropriately rather than assuming that the operation succeeded.

• Action Builder – Allows users to add, edit, configure, test, activate, deactivate, and manage OPUS Actions, as well as work with reusable OPUS Catalog Action Definitions where permitted.
  

  Assign the Action Builder role to users who develop or administer OPUS Actions.

• Action Viewer – Allows users to view OPUS Actions and their configurations. Users with this role cannot add, modify, activate, deactivate, or manage OPUS Actions.
  

  Assign the Action Viewer role to users who only need to view configured actions.

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 OPUS 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.