Multiple CLM Contexts and Clusters for Data Segregation

[Former Member]

Hi Experts,

I am trying to understand the aspects to be considered when we set up multiple contexts for an organization for segregating data between its companies.

1. Can the two contexts share the same set of users in the LDAP? How is this handled? If shared, would there be any issues with SSO?

2. Will there be two different URLs for the two companies to access? I see that two clusters cannot be created with the same hostname. I understand the master data and transactional data are separated. If in future the companies decide to provide visibility to each other's work, what would be the procedure to provide this access when they sit in two separate clusters? Would it require creation of the users in both the clusters?

3. Is there any other object / data that is shared between clusters?

4. I believe the integration configurations would have to be repeated for the second cluster? Would there be any considerations around the two clusters connecting to the same ECC system?

5. Would there be anything to consider around the supplier access to the documents across two clusters? Would there be a single URL for the supplier or two?

In essence, the requirement I am trying to design around is that the two companies in the same org should not be able to see the transactional data (contract prices etc.) of each other. Master data sharing is acceptable since there is a common ECC. However, the standard reports like 'Search Master Agreements' provide a snapshot of almost all the information on a contract by working with the advanced list page filters. This is something that is not acceptable for the companies. Any recommendations on how I can design for the above requirement without necessarily separating the data out into two contexts and clusters?

Thanks & Regards,

Subhasini

[former_member89217 · Accepted solution]

I assume the context you refer to is an enterprise context. If this is the casethe answers to your questions are as follows:

1.  there will be seperate users. so if user A needs to be in both contexts they would have two seperate accounts. may or may not have the same password.

2. There will be seperate URLs. each context has a cluster and the hostname needs to be unique across clusters in a system. It can ultimately be the same server but each context needs a unique hostname.

3. the only shared "data" across enterprises are system scoped objects system properties and localized resources are the ones that come to mind.

4. Each context (enterprise) would have its own integration setup.

5. suppliers same as buyers would have seperate logins for each context.

this particular solution provides 100% segregation. However nothing is shared so each context will require its own et of master data and configurations. 

[Former Member · Accepted solution]

Hi Gary,

Thanks for the inputs.

Yes I was referring to the enterprise context. So if our requirement is to share master data, I understand we would then have to go with a single context.

In a single enterprise context, if we are to restrict sharing / visibility of transactional data, would we have to modify all reports, add the companies as ACL and create different workbenches for the different companies?

Is there an easier alternative to achieve transactional data segregation in reports?

Appreciate your inputs.

Thanks & Regards,

Subhasini