A NetDocuments repository cabinet structure is the design of how your organization’s single NetDocuments repository is divided into cabinets, and how each cabinet’s administrators, profile attributes, workspaces, and default security are set. Get it right and the platform stays easy to search and govern as it grows from thousands to millions of documents. Get it wrong and every new practice area, confidential project, or reorganization turns into a restructuring exercise.
This guide covers the design decisions in the order you should make them. It applies to a new repository and to one that has grown without a plan.
What is a NetDocuments repository cabinet structure?
A NetDocuments repository cabinet structure is the layout of one organization-wide repository, the cabinets inside it, and the workspaces and folders inside each cabinet. Structure saves time: 2024 estimates put time lost organizing, storing, and managing agreements at 6,000 hours a year per business function. The repository holds shared settings for everyone, while each cabinet is independent and carries its own security, enabled fields, and administrators.
- Repository. The account for your whole organization. It holds users, user groups, the master list of profile attributes, their lookup tables, and the cabinets themselves.
- Cabinet. A container that holds documents, folders, and workspaces. Each cabinet sets its own membership list and default access, so it acts as a security boundary.
- Workspace. A matter-centric view inside a cabinet, built from a parent attribute such as client, or a parent and child pair such as client and matter.
A client list maintained once at the repository level serves every cabinet that needs it.
Who administers a NetDocuments repository and its cabinets?
A NetDocuments repository is administered by two distinct roles: repository administrators, who manage users, groups, and profile attributes, and cabinet administrators, who manage the settings of the specific cabinets they are assigned. Knowing which role owns a task prevents many stalled admin requests.
The split has practical consequences. Only a repository administrator can add new profile attributes such as clients, matters, and document types, even when the attribute organizes a single cabinet.
Repository administrators add and remove users, manage group membership, create profile attributes and lookup tables, create new cabinets, and review activity logs. Keep this group to two or three people. Cabinet administrators manage cabinet settings, default security, enabled fields, and workspace settings, and can unlock, roll back, or permanently delete documents. They can see every document in the cabinet regardless of its security, so assign the role with care.
How many cabinets should a NetDocuments repository have?
A NetDocuments repository should have as few cabinets as your security and lifecycle needs allow, because each cabinet adds its own settings, membership, and administrators to govern. Keeping the number of cabinets low makes the repository easier to use, and two to five cabinets cover the needs of many legal departments.
Create a new cabinet only when content differs from existing cabinets in a way that settings inside one cabinet cannot handle.
- Different audience. Board papers, HR investigations, or executive material that only a small group should ever see belong in their own cabinet with its own membership list.
- Different attributes. Content organized by something other than client and matter, such as policies organized by department, may need a cabinet with its own workspace attribute.
- Different lifecycle. Closed or legally fixed records can move to an archival cabinet that restricts editing and deletion.
Splitting by team or office is usually a mistake. Teams reorganize, and moving documents between cabinets requires administer rights on every item and changes their security.
How should NetDocuments profile attributes and lookup tables be designed?
NetDocuments profile attributes should be designed at the repository level as a short, controlled set of fields, each backed by a lookup table wherever the values are known in advance. Attributes drive search, workspace creation, and security, so their design outlasts almost every other decision.
A typical legal department needs a parent and child pair for matters, a document type field, and an author or owner field. Each extra attribute adds a field for users to complete, and incomplete fields weaken search.
- Lookup tables. Tie client, matter, and document type to validation tables so users pick from a list. Free-text entry produces spelling variants that break filters and saved searches.
- Automated feeds. Populate client and matter tables from your matter management or practice system. A new matter should appear in NetDocuments the day it opens, without a manual request.
- Parent and child pairs. Link matter to client as a parent-child lookup, so the matter list narrows to the selected client and no document is filed under another client’s matter.
How do NetDocuments workspaces fit into the cabinet structure?
NetDocuments workspaces fit into the cabinet structure as the organizing layer inside a cabinet, generated automatically from the cabinet’s workspace attributes. The cabinet decides which attribute creates workspaces, and a template decides what each new workspace contains.
Keep the template lean. Five to eight standard folders or filters, such as correspondence, agreements, and pleadings, cover most matters, and users can add folders where a matter needs more. Workspace filters work like a folder and a saved search combined, showing documents by an attribute such as document type, and they stay accurate without manual filing. Set the cabinet flag that restricts top-level folder creation to cabinet administrators, or personal folders multiply in the navigation pane for every user.
How should NetDocuments cabinet default security be set?
NetDocuments cabinet default security should be set through the cabinet membership list, giving each user group the access level new documents receive automatically. Access levels build from View up to View, Edit, Share, and Administer, and most teams should receive View and Edit rights by default.
Security design deserves this attention because most risk comes from ordinary use. User behavior is a leading risk, and an analysis of 12,195 confirmed breaches found credential abuse was the most common way attackers got in, at 22 percent.
- Groups, never individuals. Grant cabinet access to user groups managed by the repository administrator. Individual grants are hard to audit and are forgotten when people change roles.
- No Default Access. Use this setting for groups that should see the cabinet but receive rights only to documents explicitly shared with them, such as a support team that works on specific matters.
- External groups. Keep outside counsel and other external groups at No Default Access, and share with them through a workspace or CollabSpace so they see only what is shared.
When should NetDocuments profile-based security be used?
NetDocuments profile-based security should be used when access follows a profile value consistently, such as every document for a sensitive client or every document authored by a particular team. The platform applies the specified access whenever that value is set on a document.
Profile-based security is easy to overuse, since each rule adds another source of permissions to explain during an audit. It fits a small number of clients or matters with contractual confidentiality terms, where access must follow the matter value without manual steps. It fits poorly for general team access that cabinet defaults and workspace security already handle. Keep a written register of every rule, its purpose, and its owner.
How do you govern a NetDocuments cabinet structure as it grows?
A NetDocuments cabinet structure is governed through naming standards, a written design record, and change control for anything that alters cabinets, attributes, templates, or security. NetDocuments updates its core software once a quarter, and each release is a reason to confirm your configuration still behaves as designed.
- Naming standards. Name cabinets by content and audience, such as Legal Matters or HR Confidential, so a name still fits after the team or office behind it reorganizes.
- Design record. Document every cabinet, attribute, template, group, and security rule with the reason behind it, because undocumented configuration becomes technical debt the next administrator inherits.
- Change control. Configured legal platforms need a release process that tests changes before they reach users. Treat a new cabinet or attribute the same way.
How do you test a NetDocuments repository cabinet structure before go-live?
You test a NetDocuments repository cabinet structure before go-live by logging in as real users from each group and confirming what they can see, edit, and share in every cabinet and workspace. Test the structure with realistic content, including confidential matters and archived records.
Role-based security testing before go-live keeps access errors out of production, and it matters more in NetDocuments because inheritance can pass the wrong access to thousands of documents at once.
Conclusion
A NetDocuments repository cabinet structure works best when it is small at the top and disciplined underneath: few cabinets, a controlled set of attributes, lean workspace templates, and default security granted to groups. Each of those choices is cheap to make before content arrives and expensive to reverse afterward. Settle the design, write it down, test it with real roles, and your repository will scale with your matter volume.
How Basla can help
Basla provides certified delivery team members for NetDocuments implementation through staff augmentation or Basla-managed delivery. Basla business analysts capture requirements and document cabinet, attribute, and security design. QA specialists test access with real user roles before go-live, and documentation specialists produce the design specifications and administrator guides your team relies on after launch.
Basla also supports platforms through hypercare and ongoing administration. Across its legal technology services, Basla has supported deployments spanning more than 100 jurisdictions for a global retail organization and has scaled delivery teams to twice their size to meet compressed implementation timelines.
Frequently asked questions
What is a NetDocuments repository cabinet structure?
A NetDocuments repository cabinet structure is the design of one organization-wide repository and the cabinets, workspaces, and folders inside it. The repository holds users, groups, and profile attributes, while each cabinet sets its own security and administrators.
What is the difference between a repository administrator and a cabinet administrator?
A repository administrator manages users, groups, profile attributes, lookup tables, and new cabinets across NetDocuments. A cabinet administrator manages settings and default security for assigned cabinets and can see every document in them.
How many cabinets should NetDocuments have?
NetDocuments should have as few cabinets as security and lifecycle needs allow, and two to five cabinets cover many legal departments. Create a new cabinet only for a different audience, different attributes, or a different record lifecycle.
Can a cabinet administrator add new profile attributes?
A cabinet administrator cannot add new profile attributes in NetDocuments. Creating attributes such as client, matter, or document type requires repository administrator rights, even when the attribute is used by a single cabinet.
What does No Default Access mean in NetDocuments?
No Default Access in NetDocuments lets a user group see a cabinet without receiving automatic rights to its documents. Members of that group can open only documents or folders that are explicitly shared with them.
When should profile-based security be used in NetDocuments?
Profile-based security in NetDocuments should be used when access follows a profile value consistently, such as a confidential client or matter. For general team access, cabinet defaults and workspace security are easier to audit.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*