  

 

Tracelink University

 ## Breadcrumb

1. [Home](/)
2. [Resources](/resources/resource-center)
3. [TraceLink University](/resources/tracelink-university)
 
  

 

 

# Owners, Partners, Membership and Data Access Control

 

 

 

 

 

 

 

 

- [Download PDF](/node/30491/pdf)
- [Share](#)
    - [ LinkedIn ](https://www.linkedin.com/shareArticle?mini=true&url=https://www.tracelink.com/resources/tracelink-university/owners-partners-membership-and-data-access-control&title=Owners, Partners, Membership and Data Access Control&summary=This blog explains how TraceLink's platform manages data access control using the concepts of application ownership, partnerships, and process networks. It details how application owners, users, and partners interact within enterprise and multi-enterprise applications, emphasizing the flexibility of user memberships and the importance of access control mechanisms, especially in the OPUS platform.
        
        
        
        
        &source=TraceLink "LinkedIn")
    - [ Facebook ](https://www.facebook.com/share.php?u=https://www.tracelink.com/resources/tracelink-university/owners-partners-membership-and-data-access-control&t=Owners, Partners, Membership and Data Access Control "Facebook")
    - [ Mail ](mailto:?subject=Owners, Partners, Membership and Data Access Control+|+TraceLink&body=https://www.tracelink.com/resources/tracelink-university/owners-partners-membership-and-data-access-control "Mail")
    - [ Twitter ](https://twitter.com/intent/tweet?text=Owners, Partners, Membership and Data Access Control https://www.tracelink.com/resources/tracelink-university/owners-partners-membership-and-data-access-control&via=TraceLink "Twitter")
 
 

 

 

 

 

#### Table of contents

 

 

 

Blog post by: Robert Sturim, TraceLink Chief Technology Officer

In my last blog post, Ownership, I discussed the concept of application owners on the TraceLink platform. This week I want to extend the discussion to include partners and process networks and discuss how those concepts drive data access control.

Last week, I described **Application Owners**. All applications on the TraceLink platform have a clear owner – the company that licenses the application and therefore owns the data stored within that application. Some applications, such as APT, are licensed to TraceLink customers. Other applications – **System Applications**, such as the workflow manager or the metadata manager – are owned by the Prometheus company.

Applications that are licensed to TraceLink customers are either **Enterprise Applications** or **Multi-Enterprise Applications**. The licensee of such an application is the **Application Owner**. Application owners always have access to the data stored in that application. Additionally, for Enterprise/Multi-Enterprise applications, the application owner establishes links to other companies and locations. Once linked, those companies and locations are known as **partners** in the context of that application.

In a multi-enterprise application, the application owner can link to any company or location on the TraceLink network. In some cases, partners can include the locations of the application owner. Consider for example a pharmaceutical company, Bob’s Super Drug (BSD). This company has two different products – Super Smart Brain Pills are manufactured at BSD Boston – a plant owned and operated by Bob’s Super Drug. For the other product line Super Sleep Aid, BSD had contracted with a contract manufacturer (or CMO), Pills-R-Us. BSD licenses TraceLink’s Serial Number Exchange (SNX) application. Its network might look as follows:

![](https://www.tracelink.com/sites/default/files/inline-images/image_3.png)In the context of BSD’s SNX application, BSD has created two links – one to its own BSD Boston Location, and one to the Pills-R-Us company.

Enterprise applications are similar to multi-enterprise applications with one caveat – in enterprise applications, the application owner only links to locations owned by the application owner. An enterprise application cannot link to 3rd party companies or locations.

## Membership

A user can be a member of an application. **Users are members of an application in the context of a network node.** This is a key concept. A user can be a member of the application at the owning company, in which case the user is said to be a member as an application owner. A user can be a member of an application at one or more partner companies and locations, in which case the user is said to be a member as a partner.

Data in an enterprise or multi-enterprise application is often associated with a partner. In our example above, SNX is used by production lines to request serial numbers that can be placed onto packages (e.g., bottles) as they are manufactured. For SNX requests sent by BSD Boston, those requests are associated with the BSD Boston partner, and likewise, requests sent by Pills-R-Us are associated with the Pills-R-Us partner.

Users who are members as application owners have access to data across all partners. In our example above, a user who is a member at BSD can see all SNX requests, including those sent by BSD Boston as well as those sent by Pills-R-Us.

Users who are not members as an owner, but are a member at a partner, can only see those transactions associated with that partner. In our example above a user who is a member of BSD Boston can only see requests sent by BSD Boston. They cannot see those requests sent by Pills-R-Us. Note that this user may indeed be an employee of BSD, but since they are not a member at the owning network node, that user can only see a subset of the data.

Users can have multiple memberships in an application. It is possible that the same user could be a member as an owner and as a partner. In this case, the fact the user is a member as an owner entitles that user to see data across all partners. Users who are not an owner but have multiple partner memberships can see the data associated with each of those partners.



In the LSC platform, application membership was limited to company members. That is to say, a user could only be a member of an application as an owner if that user was a member of the company that owned the application. And, a user could only be a member as a partner if that user was a member of the partner company or a member of the company that owned the partner location.

In OPUS, we made a deliberate decision to remove this constraint. **Any user can be made** **a** **member of an application or a process network as the owner or as a partner regardless of the company to which that user is associated.** This better supports a number of use cases. For example, the user could be a contractor and consultant, employed by a third party but still doing work for the owner or partner. It also allows companies to make TraceLink support users members of their applications and process networks.

***On the OPUS platform, company membership has (almost) no bearing on determining what a user is allowed to see or do. In (almost) all cases, a user's access is based upon application or process network membership, not company membership.***

Please take a moment to reread that prior paragraph and make sure you understand it. I cannot stress this concept strongly enough. ***If you are basing any application or process network authorization logic on a user's membership in a company, you are almost certainly doing it wrong.***





System applications do not typically have members. The standard pattern is for system applications to delegate questions regarding user authorization to an enterprise application.

Thus far I’ve mentioned enterprise applications, multi-enterprise applications, and system applications. For completeness, there is a fourth type of application in OPUS – a user application. Like system apps, user apps are owned by Prometheus, and users are not members of user applications. Unlike system applications, users can interact directly with user applications without proxying those calls (and authorization logic) through an enterprise application. The main criterion for an application to be a user application is that data access is based solely on the identity of the user.

A good example of a user application is the message center. Companies do not need to license the message center. Users do not need to be made a member of the message center application. The message a user is allowed to see in the message center is based solely on that user’s identity. That is to say, a user is allowed to see messages addressed to that user, and no other messages.

## Process Networks

OPUS introduced the concept of process networks. Process Networks allow application owners to create multiple networks of users and partners in the context of an application. Agile Process Networks (APT) is the first application to take full advantage of process networks. The application owner may choose to create different process networks for different product lines, especially if the employees who manage those products or the partners who support those products are distinct. Or, the application owner may choose to create different process networks for different APT processes.

Many of the same concepts that I described in the previous sections apply to process networks. Process networks are owned by the application owner. A company or location can be made a partner of a process network. Partners of a process network can also include locations of the application owner. Users are members of a process network in the context of a network node, and a user’s access to that data in a process network is determined by whether that membership is at the owning company or a partner network node.

The NAA application which manages network objects has additional data structures for managing process networks, process network partners, and process network members, that are similar to applications, application partners, and application memberships. When a partner is made a partner of a process network, OPUS will automatically make that user a member of the application as well if they are not already one. And, when a user is made a member of a process network at a network node, OPUS will automatically make that user a member of that network node at the application level as well if they are not already one. Thus the application partners and memberships are essentially a union of process network partners and process network members.

Older applications, such as those that currently reside in the LSC, do not support process networks. Applications such as SOM, SNX, SNM, and Product Track only support application membership and partnership within Network Objects. In the OPUS user experience, we present a unified network paradigm to our users. By selecting a network from the network dropdown, the user is choosing the context in which they wish to operate. For applications such as APT, the user is typically selecting a process network. For applications such as SOM, SNX, SNM, and Product, we present such applications as having a single network. The user experience insulates the user from these details.



You may have heard the concept of a virtual process network. This is an approach we leveraged to support the network paradigm in the user experience, and allows the front end to treat applications as though they were process networks in the case of applications that do not directly support process networks.





## WorldView

WorldView enforces data access control. WorldView reads the user’s authorization token to determine whether a user is a member of an application or process network, and restricts a user’s access to the data accordingly.

Developers are able to enable/disable the logic relating to automatic enforcement of access control based upon partner links by turning link access control on or off. This feature exists for system applications and user applications. Such applications do not support partner links, and in that context, such logic does not make sense. **Enterprise Applications and Multi-Enterprise Applications should always enable the linking access control unless there is a specific and deliberate reason for disabling it.** Having this feature enabled should make application development easier. More importantly, having this feature enabled removes the possibility of a coding error allowing data to be leaked to partners who should not have access to it.



 

 [TraceLink University](/tags/tracelink-university) 

 

 

 

#### Table of contents

 

 

 

 

 

 



 

##### Related Content

 

 [ ![Page Types](https://www.tracelink.com/sites/default/files/styles/resize_image_style_640_480/public/2024-09/ose-page-types.png.webp?itok=dOirwcMj) ](/resources/tracelink-university/understanding-page-types-within-opus-solution-environment-ose) 

#####  Understanding Page Types within the OPUS Solution Environment (OSE) 

 Page types enable Solution Designers to efficiently create user-friendly pages using a drag-and-drop interface, allowing them to organize information for optimal usability. 

 

 [View More](/resources/tracelink-university/understanding-page-types-within-opus-solution-environment-ose) 

 

 [ ![Anthem Design Guide](https://www.tracelink.com/sites/default/files/styles/resize_image_style_640_480/public/2024-09/Design%20Guides-2.jpg.webp?itok=EUXgrbF9) ](/resources/tracelink-university/ux-writing-and-terminology) 

#####  UX Writing and Terminology 

 The goal is to create UI text that is clear and concise, offering users the essential information they need to effectively complete their tasks. 

 

 [View More](/resources/tracelink-university/ux-writing-and-terminology) 

 

 [ ![Opus Ensemble UX](https://www.tracelink.com/sites/default/files/styles/resize_image_style_640_480/public/2024-09/opus-ensemble-zoom-02.png.webp?itok=FWCuHxjz) ](/resources/tracelink-university/introducing-opus-ensemble) 

#####  Introducing OPUS Ensemble 

 TraceLink's OPUS Ensemble, the first next-generation solution on the OPUS Platform, revolutionizes user interaction by seamlessly integrating personalized settings, powerful navigation, and company-specific context for efficient access to notifications, support, and essential tools. 

 

 [View More](/resources/tracelink-university/introducing-opus-ensemble) 

 

 [ ![Opus Ensemble](https://www.tracelink.com/sites/default/files/styles/resize_image_style_640_480/public/2024-09/ose-closeup-ensemble-annotated.png.webp?itok=DuYz492d) ](/resources/tracelink-university/opus-ensemble-patterns) 

#####  OPUS Ensemble Patterns 

 Enabling OPUS Solution Designers to understand Ensemble patterns, which includes user context, settings, and browser-style navigation for streamlined access. 

 

 [View More](/resources/tracelink-university/opus-ensemble-patterns) 

 

 [ ![Sample](https://www.tracelink.com/sites/default/files/styles/resize_image_style_640_480/public/2024-09/For%20Internal%2095_0.png.webp?itok=QysU6iAe) ](/resources/tracelink-university/define-and-design-search-pages) 

#####  Define and Design Search Pages 

 Search pages enable users to view, search for, and create new object instances, typically serving as the landing page when navigating to a solution, except when only one instance exists (like the Profile page in Settings), in which case the user is directed to the View/Edit page. 

 

 [View More](/resources/tracelink-university/define-and-design-search-pages) 

 

 [ ![Workflows](https://www.tracelink.com/sites/default/files/styles/resize_image_style_640_480/public/2024-09/Developer%20Documentation.jpg.webp?itok=E6LBqYmQ) ](/resources/tracelink-university/define-and-design-workflows) 

#####  Define and Design Workflows 

 This guidance outlines essential practices for designing effective workflows that enhance efficiency and flexibility in business processes, focusing on primary objects to help OPUS Solution Designers create impactful solutions. 

 

 [View More](/resources/tracelink-university/define-and-design-workflows)