Concepts and terminology

Solutions pull together configurable assets (i.e. object types within the data model, workflows, user experience tasks, roles, and policies) that define certain elements of an app's behavior. Each solution is developed for use with a specific type of app (e.g. Agile Process Teams), and can be applied to that app or one of the app's networks, deploying the solution’s functionality to users.

In Solution Designer, solution version 9.0, TraceLink installs solutions and applies solutions to apps and networks on behalf of companies, which deploys the solution’s functionality to the company's users.

Solutions have assets, which primarily consist of object types within the data model, workflows, user experience tasks, roles, and policies. Although a solution pulls together these assets, the assets themselves are independent and can be reused across many solutions. For example, a Solution Developer can configure the permissions for a single role, and reuse that role in many solutions where it is relevant.

A package is a portable version of a solution that preserves the state of the solution and the assets that the solution uses and can be downloaded and imported. Companies can view and save packages for apps that they have licensed. For example, if a company owns Agile Process Teams (APT), the Supply Chain Work Management package, which is licensed with APT, is available to that company. Once saved, a company can install a solution from the package to make the solution and its assets available within the environment that is currently selected.

Saved packages are stored in the company's local library, which acts as a company’s local storage for package files. Each company can maintain their collection of packages in their local library. Companies save solution packages from the available packages and add them to their local library, save their local solution customizations as packages to their local library, and use their local library to move packages between environments (i.e. from Validation to Production).

Solutions always exist within a single environment (e.g. Validation) but can be moved between environments using packages.

TraceLink applies solutions to apps and their networks on behalf of companies to customize the app or network behavior. The assets associated to the applied solution determine some of the app's functionality and supply certain configuration options for the app.

Contact TraceLink Support to apply a solution to an app or network.

Object types are one of the assets that solutions use. Object types represent the business concepts within the app (e.g. products, shipments). For example, the directSupplierIncident object type for Agile Process Teams represents direct supplier incidents.

Object types fall into one of the following categories:

• Base object types, which are developed for the app. Solution Developers cannot modify or remove base object types.
• Sub-object types, which are added by a Solution Developer for customization purposes. Sub-object types are extended from base object types, and Solution Developers can modify sub-object types as needed.

Solution Developers customize solutions by specifying which base object types and sub-object types the solution uses.

Object types can have one or more attributes (e.g. data fields), which describe the object type and provide it with context. For example, the Material Type attribute associated with the directSupplierIncident object type for Agile Process Teams indicates that a material type is one characteristic of direct supplier incidents.

Attributes can also have one or more rules, which provide the attribute with additional data logic. For example, the Material Type attribute could have a rule that provides a list of allowed values to select from.

The app's base object types are developed with standard attributes. For base object types, standard attributes are not customizable.

Sub-object types inherit the standard attributes of the base object type that the sub-object type is extended from. For sub-object types, the standard attributes cannot be modified, however, Solution Developers can add rules to them.

Solution Developers can also add custom attributes for sub-object types. Custom attributes can only be customized by the Solution Developer's company, and Solution Developers can add rules to the custom attributes as needed.

Object types—with their associated attributes and rules—can be shared across solutions within an environment, as long as the solutions are for the same app. For example, Object Type X can be used by both Solution A and Solution B, as long as Solution A and Solution B are both for the same app.

Workflows are one of the assets that solutions use. Workflows represent the process logic for an object type. Each object type in the data model can have exactly one active workflow associated to it. Workflows are composed of states and transitions, which can have conditions and actions.

Workflows fall into one of the following categories:

• Base workflows, which are developed for specific base object types within the app. Solution Developers cannot modify or remove base workflows.
• Sub-workflows, which are added by a Solution Developer for customization purposes. Sub-workflows are extended from base workflows, and Solution Developers can modify sub-workflows as needed.

Solution Developers customize solutions by specifying which base workflows and sub-workflows the solution uses for the workflow's associated object type.

Workflows have states, which define the statuses that the object type can have (e.g. Not Started, Under Investigation, and Completed for an object type of directSupplierIncident).

States fall into one of the following categories:

• Base states, which are developed for base workflows. Solution Developers cannot modify or remove base states.
• Sub-states, which are added by a Solution Developer for customization purposes. Solution Developers can modify sub-states as needed.

In addition to states, workflows also have transitions, which define the movement from one state to another (e.g. a transition can move an object type from the Not Started state to the Under Investigation state).

Transitions can have actions and conditions, which provide additional logic for the movement between states.

When modifying a sub-workflow, sub-state transitions must adhere to the same base state transitions from the base workflow.

Workflows—with their associated states, transitions, conditions, and actions—can be shared across solutions within an environment, as long as the solutions are for the same app. Additionally, to use a workflow with a solution, the solution must also use the workflow's associated base object type or a sub-object type extended from that base object type. For example, Workflow X, which is associated to Object Type X, can be used by both Solution A and Solution B, as long as Solution A and Solution B are both for the same app and use Object Type X or one of its sub-object types.

Tasks are one of the assets that solutions use. Tasks display below the Do side menu item and allow users to navigate to the different tasks they need to accomplish within the Network, Team, and Process selected in the top navigation. For example, Monitor Incidents is a task within the Incident - Direct Supplier process for Agile Process Teams.

Tasks provide access to screens, which display in the main content area below the header and to the right of the side menu. A single task can have many screens.

Screens contain components, which render objects in the UI (e.g. tables and charts). Solution Developers can customize the behavior of a component by configuring its properties and events.

See the Anthem Design Guide for the customizations available for each component.

Tasks—with their associated screens and components—can be shared across solutions at the environment level, even if the solutions are for different apps. For example, Task X can be used by both Solution A and Solution B, even if Solution A and Solution B are for different apps.

Roles are one of the assets that solutions use. Roles group together one or more permissions to define various levels of access that can be assigned to users in Administer.

Roles group together permissions, which define a more granular level of access within the Opus Platform. Some permissions are developed for the app. However, Solution Developers can also add permissions when configuring policies.

Roles—with their associated permissions—can be shared across solutions within an environment, as long as the solutions are for the same app. For example, Role X can be used by both Solution A and Solution B, as long as Solution A and Solution B are both for the same app.

Policies are one of the assets that solutions use. Policies define access to apps at the API endpoint level and supply logic for the permissions that Solution Developers associate with roles.

Policies can be applied to one or more enforcement points, which are the gateways to various parts of the API. Solution Developers apply policies to enforcement points to define where the policy is invoked. When a policy is applied to an enforcement point, the policy is active for all users that interact with the app, regardless of their role.

Although a single policy can be applied to multiple enforcement points, each enforcement point can only have one policy applied to it at a time.

Policies fall into one of the following categories:

• Standard policies, which are developed at the platform level. Solution Developers cannot modify or remove standard policies, but they can specify which enforcement points they are applied to.
• Custom policies, which are added by a Solution Developer for customization purposes. Solution Developers can modify custom policies and apply them to enforcement points as needed.

Policies can reference permissions, which allow Solution Developers to make the policy active at the user level, rather than at the app level. Solution Developers select which permissions to enable when customizing roles, so the policy is active only for users that have the corresponding role assigned.

Policies and permissions are always shared across all solutions within an environment, even if the solutions are for different apps (i.e. all solutions in the environment use all policies and permissions in the environment, and Solution Developers do not specify which policies and permissions a solution uses). For example, Policy X and Permission Y are both used by both Solution A and Solution B, even if Solution A and Solution B are for different apps.

Although policies and permissions are shared across solutions, the enforcement points that a policy is applied to are specific within a solution. For example, Policy X can be applied to enforcement points H, I, and J within Solution A, and enforcement points K, L, and M within Solution B, though the policy's logic is shared across both solutions.