Design Considerations With Roles and Policies

Overview

Users’ access to data and operations in a solution is controlled by permissions, roles, and policies. Each of these elements is defined separately, but all 3 work together to protect your data and ensure your solution meets your company’s security standards.

• Permissions govern what a user can and cannot do inside OPUS. For example, a TraceLink product might have separate permissions that allow users to view existing purchase orders, edit existing purchase orders, or create new purchase orders. Each TraceLink product comes with a set of predefined permissions. Solution Designers cannot modify permissions.
• Roles group together one or more permissions to define the level of access that can be assigned to a user. For example, instead of needing to assign 3 separate permissions to a user so they can view, edit, and create purchase orders, those permissions can all be included in a single role called Manufacturing - Customer. The role can then be assigned to one or more users at the same time, drastically reducing the chances that the incorrect permissions will be given to a user and ensuring that all users of the same type have the same level of access. Solution Designers can create new roles or modify existing roles by adding or removing permissions.
• Policies supply the logic for the permissions that are associated with a role. In most cases, the policies included in a Standard or Marketplace solution (i.e. the solution your Company Solution is based on) handle role-based authorization, which verifies that the user is assigned to a role that has permission to perform a given action. A policy is associated with an enforcement point, which is the point in a process where TraceLink checks that the current user has permission to perform the attempted action. Solution Designers can update a policy if their product requires security logic that is not supported by existing permissions. For example, if there are not different permissions for users to create new domestic purchase orders and new international purchase orders, a Solution Designer could create 2 separate roles and modify the logic of the policy to ensure that only the appropriate role could create a domestic or international purchase order. Modifying policies is an advanced topic that Solution Designers should not attempt without consulting with their company’s security team and their TraceLink Services representative.

Permissions Patterns

TraceLink solutions come with a standard set of permissions out-of-the-box:

• Search
• New
• View
• Edit
• Delete
• Import
• Export
• Custom Operation

When creating or editing a role, these permissions are applied to the object types defined in the solution to define the operations the user with the given role can perform.

Role Patterns

Roles in Standard and Marketplace Solutions are created to support the use cases and business needs that are met by those solutions, not to support every possible use case. They reflect the scope of the Standard or Marketplace Solution, which could be much different from the scope of a Company Solution. Therefore, when considering roles for a Company Solution, start by considering the use cases that are unique to your company, and extrapolate from that the roles necessary to meet those use cases. For example, MINT supports 4 different orchestrations (Manufacturing, Logistics, Commerce, and Clinical Supply), each of which has unique tasks for inbound and outbound messages. Therefore, MINT provides 8 out-of-the-box roles to support the use cases for those different orchestrations. Companies with more use cases involving the Clinical Supply orchestration may want to have more roles in that domain, so they would be created as part of their Company Solution.

The name of a role should be meaningful and speak to the work that will be performed by users with that role. Instead of providing general names (e.g. User, Member, Advanced Member), use descriptive names that indicate the tasks the user will perform or the department in your organization whose members will have the role (e.g. Development Operations, Clinical Trials Client Services). Even if your solution has only one role, resist the urge to give the role a vague name, so your role names can scale along with your company.

Common Roles

Every company must have at least one user with the role of System Administrator, and each TraceLink product licensed by a company should have at least one user with the role of TraceLink Administrator. Otherwise, the roles within a product depend on how the company divides its responsibilities among its employees and the data the product works with. A small company with only a few users may have a small number of roles with access to most or all of the functionality within a product, while a larger company that compartmentalizes its data would have more roles with more limited scope. It is common that a solution for a product that handles a large number of use cases or orchestrations will have a role for decision-makers or stakeholders whose domain spans multiple use cases to view most or all of the data in the solution.

Configuration

Before you design your company solution’s roles, you need to have comprehensive knowledge not only of the solution’s operations and the use cases the solution solves, but also the existing workflows and your company’s org chart. If you know who the users are, what they need to do, what object types they need to work with, and when in the process they need to do it, configuring the roles should be a simple task.

The only configuration possible in OPUS Solution Environment (OSE) is applying permissions to the object types in the solution and specifying whether or not the solution’s menus are visible in the side menu. The object type permissions have self-explanatory names and map to the typical tasks that users will perform on the object types. The menus should already be defined based on the solution’s object types, so specifying the menu entries that appear in the side menu should naturally arise from the operations the role can perform.

Note that an Administrator role within a product does not automatically grant Standard Access or Expanded Access to users with that role.

Creating Company Roles

To learn more about how to add new roles and modify existing roles in the OPUS Solution Environment, see the OPUS Solution Environment (OSE) Help Center.

Assigning Users to Roles

To learn more about how to apply roles to users with the Administration solution, see the Administration Help.