Post

2 followers Follow
0

Help with adding a third attribute to a cabinet

I am a new admin to NetDocuments, and am having trouble. We currently have a cabinet based on workspaces. There are 2 attributes, Client (parent) and Project (child). I need to add a 3rd attribute (deal type) that becomes the child of Project (parent). 

                                                 Client

                           Project                                      Project

           Deal Type      Deal Type                          Deal Type

I have created the new attribute (Deal Type) at the repository level, and selected the attribute to be used at the cabinet level. It doesn't display anywhere in the new cabinet. This is where I would like to see the 3rd attribute, when navigating to a workspace. I have searched online and the support site and don't understand what I'm missing. 

Any guidance would be appreciated. 

Thanks, 

Laura

Status: Answered

Please sign in to leave a comment.

9 comments

0
Avatar

Laura,

There is currently not a way to have a "grand-child" attribute, or a child of another child. There are some alternatives you could try, depending on how you plan to use these attributes. 

0 votes
0
Avatar

Russell, 

Thanks for the reply. At least 2 associates on the NetDocs support staff have told me that it is possible... I can't find any documentation regarding this... I'm not sure how/where to proceed. 

 

Here's some more info;

Client = a company

project = building / property

We often complete multiple transactions on the same project. Workspaces still make sense to sort by doc-type. However we need a way to separate transactions per project. We are trying to avoid having multiple cabinets for each transaction type... that would cause documents for the same project to be in different cabinets, which may not be ideal. 

Any suggestions are welcome! 

Thanks, 

Laura

0 votes
0
Avatar

I'm not sure how multiple cabinets would help in this case. Either way, a document can only exist in one cabinet at a time.

Will each Deal Type under each Project be unique? Or will a given Deal Type apply to multiple projects or clients? For example, in a legal environment, a Matter may be a Litigation (law type), while another matter under the same client may be a transaction, but other Matters under other clients might also be a Litigation. In this case, the "type" doesn't reside "under" the Project/Matter. 

Or, are you hoping to base workspaces on Deal Type, so each Deal Type has its own workspace? In this case, can you add the Deal Type information to the Project table? Project1-DealTypeA would be one workspace, and Project1-Deal TypeB would be another workspace. 

0 votes
0
Avatar

The Deal Type will not be 'under' the project. In the example below, this is exactly what we want to do... is there a way to do this without simply creating another project with the deal types in the names? 

Our naming convention and length are concerns. There are also concerns regarding eDiscovery, and the 2 deal types being in the same cabinet, although I don't have much information regarding this. 

 

 

 Project1-Deal TypeA would be one workspace, and

Project1-Deal TypeB would be another workspace.

0 votes
0
Avatar

Its common for a legal setup to have a "practice area" attribute (in your case, let's say this is equivalent to Deal Type). They would relate these values (litigation, patent, M&A) to the matter (project). This allows them to search across multiple matters based on a common area of law. But, each matter belongs to only one Practice Area.  Will there ever be a case where a project may be related to multiple deal types (referring back to your original diagram)? What is the relationship between a deal type and a project?

Also, do you need to display the deal type in the name of each project? 

0 votes
0
Avatar

I thought that would be the path I would need. I created a Deal Type attribute, but don't understand how this would be visible. Would it be a separate workspace?

 

Each Project could have multiple Deal Types. I don't think displaying the deal type name/description is required in the name, however it could become confusing without it.

Client A / Laura Inc. 

      Project 1 / Fancy Building - 331 Main Street

               Deal Type X / Acquisition

                Deal Type Y / Renovation

     Project 2 / Tall Building - Historical Name - 833 South Street, Ohio

                Deal Type X / Acquisition

                Deal Type Z / Development

Sample workspace name: Laura Inc - Tall Building - Historical Name - 833 South Street, Ohio - Development

Once you add in the Deal Type in the name of the workspace it gets longer. (The existing naming convention isn't ideal either.)

 

The way I see it, without having a 'grandchild' attribute, we need to add the Deal Type into the name of the project. Each instance of the project would then have it's own workspace.  We are looking for an alternative solution. 

 

Laura

0 votes
0
Avatar

Laura,

Are you working with a certified NetDocuments Services partner? They should be able to help you sort through these configuration options. 

There are many ways to organize documents within a workspace. You could have each project have its own workspace, but users would see documents divided by Deal Type within each workspace, as well as by document type. 

0 votes
0
Avatar

Can you clarify what you mean by certified NetDocuments Services partner please? Is that a vendor that you partner with for training? A third party that has a fee?

I'm a new admin, and am not getting specific help. Does our contract/ purchase not include support regarding content organization?

0 votes
0
Avatar

NetDocuments partners with third-party technology consultants to offer services to its clients. These consultants offer training, as well as account configuration and implementation services. They generally charge a fee, but some may have free initial consulting sessions. 

For general technical support issues, such as troubleshooting errors and defects, you can contact the Global Support Team at any time, based on your service agreement. 

0 votes