NetDocuments workspaces are shared, attribute-based views that organize documents, emails, and related content around a single business context, such as a Matter, a Client, or an administrative Department. Every workspace is built on a lookup-table profile attribute chosen when the cabinet is configured, and that one decision becomes the backbone of how users navigate the cabinet every day afterward. A NetDocuments rollout that gets workspace design right the first time avoids the slow accumulation of folder sprawl that workspaces exist to prevent.
What is a NetDocuments workspace?
A NetDocuments workspace is a shared view organized around a specific business context. For context, the 2026 edition of a long-running global study puts the average cost of a data breach at $4.99 million, a record high. It replaces a manually maintained folder tree as the primary way content gets structured. A law firm’s Client/Matter cabinet typically bases its workspaces on Matter, so each open matter gets its own workspace with a predictable layout, a defined title format, and its own access controls.
- A workspace is not a folder. It is a structured container built from a controlled profile attribute, with a template behind it and security that can follow the attribute automatically.
- A workspace reduces manual maintenance. New matters, new departments, and new administrative functions get a workspace with the same starting structure every time, without someone rebuilding a folder tree by hand.
- A workspace centers work. Documents, emails, tasks, and related content all live inside the same view. Storage location is a secondary concern.
How is a workspace’s base attribute chosen?
A cabinet’s workspace base attribute is chosen during workspace-template configuration, where an administrator selects the profile attribute every workspace in that cabinet will be organized around. A legal cabinet commonly bases workspaces on Matter. An administrative cabinet commonly bases them on Subgroup.
- The base attribute must already have a lookup table. An administrator cannot select a free-text attribute as the base, and the lookup table has to be uploaded before that attribute even appears as an option.
- The choice shapes daily navigation for years. Every user’s default path into the cabinet’s content runs through whatever attribute gets picked here, and a departmental rollout that includes workspace design typically runs two to four months precisely because this decision takes real discussion.
- Match the base attribute to how people actually work. A matter-based cabinet fits legal work; a subgroup-based cabinet fits an administrative function organized by team, with engagement-style client work playing no part in the structure.
How do NetDocuments workspaces get their structure from a lookup table?
NetDocuments workspaces get their structure from a lookup table because the base attribute has to be a controlled field, never free text, before a workspace can be built from it. The lookup table turns the attribute into a predefined picklist, so every workspace title and every workspace’s place in search comes from a value someone approved in advance. Whatever a user happened to type never enters the picture.
A parent-child relationship, such as Client feeding Matter, can sit underneath the base attribute, and the child attribute is generally the one the workspace gets built on.
What is a workspace template, and how does it get applied?
A workspace template is the pattern every new workspace in a cabinet is built from: its default folder structure, its starting views, and the containers a user sees on first open. NetDocuments applies a single default template automatically, or, for Client/Matter cabinets, a specific custom template based on a Type value in the lookup table.
- A default template covers the common case. Most workspaces in a cabinet can share one structure without any special configuration.
- A custom template covers the exception. A litigation matter and a corporate transaction matter often need genuinely different starting structures.
- Templates reduce setup time to zero for the end user. A new workspace arrives with the right folders and views already in place.
How does the Type field map a lookup value to a template?
The Type field maps a lookup value to a custom workspace template by name, and the two names have to match exactly for the mapping to work. A Matter Type value of “Litigation” in the lookup table has to correspond to a workspace template also named “Litigation,” with no variation in spelling, capitalization, or punctuation. Research put poor software quality’s US cost at $2.41 trillion in 2022, and a silently broken Type-to-template mapping is the kind of unnoticed inconsistency that feeds it.
- Treat the Type value as a key. Free text invites drift. “Corporate Legal,” “Corporate-Legal,” and “Corporate legal” read as three different values to the system, never one.
- Document the mapping somewhere durable. A spreadsheet or wiki page that lists every Type value next to its template name saves the next administrator from reverse-engineering the relationship.
- Test every Type value after a template change. Renaming a template without updating the matching lookup value breaks the mapping silently.
How does Profile-Based Security protect a workspace?
Profile-Based Security protects a workspace by tying access to the same profile attribute the workspace is built on, so a new matter or a new department can inherit the correct access automatically, with no administrator configuring each one by hand. A Repository Administrator enables this once custom profile attributes are turned on for the cabinet.
- Absolute security replaces access. An entry beginning with an exclamation mark overrides the rest of the access control list; it does not add to what was already there. It needs testing before it goes live broadly.
- Test every access path. Cabinet administrators, workspace owners, group members, external users, and search results can all behave differently under a Profile-Based Security rule.
- Review inheritance on new documents. A document added after the rule goes live should inherit the intended access, and confirming that directly is safer than assuming.
What does a matter-based workspace look like next to an administrative one?
A matter-based workspace and an administrative workspace follow the same underlying mechanism with a different base attribute driving each one.
In a legal cabinet, Client feeds Matter, Matter feeds the workspace template, and the workspace title typically follows a pattern such as “Acme Corporation – Acquisition.” In an administrative cabinet, Department feeds Subgroup, Subgroup feeds the template, and the title follows a pattern such as “FIN – Accounts Payable.”
Both structures depend on the same two prerequisites: a lookup table that stays clean, and a repository-to-cabinet governance model where someone owns the schema decisions. A workspace left to evolve on its own drifts from that structure within a year.
What can users organize inside a workspace once it exists?
Once a workspace exists, users commonly organize its content using Document Type filters, folders or folder packs, saved searches, and workspace-specific views, with the available containers depending on the NetDocuments edition and enabled modules. All of them serve one purpose: keep the workspace as the unit of organization and let internal containers handle finer sorting inside it.
- Document Type filters narrow a workspace’s contents without requiring a separate folder for every category.
- Saved searches give users a repeatable view into a subset of the workspace’s content, useful for a recurring report or a status check.
- Folders still have a place, but the workspace structure should carry most of the organizational weight. A folder tree layered on top is a supplement, never the primary system.
What are the most common NetDocuments workspace mistakes?
The most common NetDocuments workspace mistakes come from treating the base attribute or the template mapping as a minor detail. It is the foundation everything else in the cabinet sits on.
- Choosing a base attribute nobody governs. If the lookup table behind it degrades, so does workspace search, workspace security, and every template mapping riding on top of it.
- Letting Type values and template names drift apart. A single spelling difference silently breaks the mapping and leaves a workspace with the wrong structure.
- Enabling absolute Profile-Based Security without a rollback plan. An access string that replaces existing access outright needs the same release discipline any other platform configuration change gets, tested before it reaches production.
- Never documenting who owns the schema. An undocumented configuration decision is a liability once the person who made it moves on, and base-attribute decisions are exactly the kind that get forgotten first.
Conclusion
NetDocuments workspaces earn their reputation as a better alternative to folder trees because the structure comes from one governed attribute. Years of ad hoc filing decisions produce the folder sprawl workspaces are built to avoid. A matter-based cabinet and an administrative cabinet run on the same mechanism: a controlled lookup value drives a template, and the template gives every new workspace a predictable shape from day one. The base attribute decision deserves a real governance conversation, because templates, security, and search depend on it staying clean for the life of the cabinet.
How Basla can help
Basla provides certified delivery team members for NetDocuments implementation, covering testing, documentation, and hypercare through staff augmentation or Basla-managed delivery. That includes workspace design worked through business analysts who choose and validate the base attribute, map Type values to templates, and test Profile-Based Security before go-live, drawing on legal technology consulting and delivery experience across matter management and eBilling rollouts spanning more than 100 jurisdictions.
For departments already living with a workspace structure that has drifted, Basla’s delivery teams can run the audit and template-remapping workstream needed to bring it back under control.
Frequently asked questions
What is a NetDocuments workspace built on?
NetDocuments workspaces are built on a single profile attribute chosen during cabinet configuration, such as Matter for a legal cabinet or Subgroup for an administrative one, and that attribute must already have a lookup table before it can be selected.
Can a workspace be based on a free-text attribute?
No. The base attribute must be a lookup-table attribute with controlled values, since a free-text field cannot generate the predictable structure a workspace template depends on.
How does a Type value connect to a workspace template?
A Type value in the lookup table has to match the name of the corresponding custom workspace template exactly, including spelling, capitalization, and punctuation, or the mapping between the two silently fails.
Does Profile-Based Security work the same way on every workspace?
Profile-Based Security follows the same base attribute the workspace is built on, but absolute security entries replace existing access outright, which is why every access path needs testing before the rule goes live broadly.
What is the difference between a matter-based and an administrative workspace?
Both use the same underlying mechanism, a lookup-table attribute feeding a workspace template, but a matter-based workspace typically runs on Client and Matter while an administrative workspace typically runs on Department and Subgroup.
Who should own the base-attribute decision for a cabinet?
A named administrator, working with whoever governs the underlying lookup table, since the base attribute decision affects workspace structure, security, and search for as long as the cabinet is in use.
*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.*