NetDocuments standard vs custom metadata fields is the distinction between the information the platform records about every document automatically, such as who created it and when, and the fields your organization defines to describe what a document is and where it belongs, such as client, matter, and document type. Standard fields describe a document’s history, and custom fields describe its meaning.
The practical question for most legal teams is where to draw the line: which custom fields earn their place, how to keep them consistent, and how to use them for workflow and security. This guide works through those decisions.
What are NetDocuments standard vs custom metadata fields?
NetDocuments standard vs custom metadata fields are two layers of the same document profile: standard fields the platform fills in by itself, and custom fields that repository administrators create and users complete. Fields also feed reporting: a 2025 survey of in-house legal teams found 77 percent still handle all or part of their reporting manually. Both appear on the profile and both are searchable, but only custom fields reflect your organization’s own structure.
Standard fields are recorded on every document without configuration, including its name, document number, file extension, and the user and date for creation and last modification, and users cannot skip them. Custom fields are profile attributes your repository administrators define, typically client or business unit, matter, document type, and author, and they are only as good as the values users enter.
Which standard metadata fields does NetDocuments record automatically?
NetDocuments records standard metadata fields covering a document’s identity and its activity history, and it captures them without any user input. These fields answer the questions of what a file is and who has touched it.
- Identity fields. Document name, a unique document number, and file extension identify each record and let users find a known document quickly.
- Version fields. Version number and file size show whether a user has the latest copy before editing or sending it.
- Activity fields. Created by, created date, last modified by, and last modified date track history.
NetDocuments stores the Created By and Last Modified By fields as text at the time each action occurred, so a user’s later name change does not rewrite older records.
Standard fields are reliable because they are automatic. What they cannot tell you is which client, matter, or document type a file belongs to, and that is where custom fields come in.
When should you create a custom metadata field in NetDocuments?
You should create a custom metadata field in NetDocuments when the field will drive something: a search, a workspace, a workflow, a report, or a security rule. A field that nobody filters on adds effort for every user and returns nothing.
A 2023 workplace survey found 62 percent of people struggle with too much time spent searching for information in their workday.
- Search. Add a field when users regularly need to narrow results by it, such as document type or jurisdiction.
- Workflow. Add a field when a document moves through stages that people need to track, such as review status or approval date.
- Security. Add a field when access should follow its value, such as a confidential client or a restricted business unit.
Give every field that passes this test a named owner.
Which custom metadata fields does a corporate legal department need?
A corporate legal department typically needs four to six custom metadata fields in NetDocuments: an organizing parent such as business unit or legal entity, a matter, a document type, and an owner or author. Additional fields should follow the same test of driving search, workflow, or security.
Corporate structures differ from law firm structures, so the fields should mirror how your department actually organizes work. Law firms use client as the top level, while legal departments usually get more value from business unit, legal entity, or region, linked as the parent of matter. Document type works best as a short list of distinct values such as agreement, correspondence, board material, and policy, because long lists produce inconsistent choices.
How do dynamic custom fields work in NetDocuments?
Dynamic custom fields in NetDocuments are attributes that appear on a profile only when a controlling value is selected, so users see extra fields only when they are relevant. They are created like any other attribute and flagged as dynamic, and the controlling value lists them by attribute number in braces.
A common example uses four dynamic attributes for received date, status, reviewer, and paid date that appear only when a disbursement invoice document type is selected. Combined with saved searches, those fields turn the repository into a simple tracking tool. Most documents never show the extra fields, so users are not asked for information that does not apply, and a status field with values such as Received, Entered, Approved, and Paid lets saved searches show exactly where each item stands.
How are custom metadata fields kept consistent in NetDocuments?
Custom metadata fields in NetDocuments are kept consistent by backing them with lookup tables, requiring values on the fields that matter, and controlling who can add new values. Consistency is what makes a custom field searchable.
- Lookup tables. Turn key fields into pick lists so users choose from approved values, maintained by administrators or loaded from a spreadsheet file.
- Required values. Set the prompt-if-empty option on client or business unit, matter, and document type, so documents cannot be saved without them.
- Controlled additions. Limit who can add lookup values to administrators and a small group of named uploaders, so a typo never becomes a permanent option.
Keep keys stable. Use matter numbers from your source system as keys, since a key cannot be changed once created.
How do custom metadata fields populate new matters automatically?
Custom metadata fields populate new matters automatically when new client and matter values flow into NetDocuments lookup tables from another system, which also creates each matter’s workspace. Law firms usually do this through their practice management integration, while corporate legal departments often need another route.
- Spreadsheet upload. Admins or designated users upload new values from a shared file. It is simple, though concurrent edits to the file can conflict.
- Third-party workspace tools. Tools built on the NetDocuments API let designated users create workspaces in the cabinets they can access.
- Power Automate. Organizations with Microsoft 365 can use the NetDocuments connector to create an approved workspace after a matter intake request is completed.
In every case, a new matter should exist in NetDocuments the day it opens.
How can custom metadata fields enforce ethical walls in NetDocuments?
Custom metadata fields can enforce ethical walls in NetDocuments through profile-based security, which assigns a security string to a lookup value so every document filed against that value inherits the restriction. Profile-based security on a client value secures everything created under that client from that day forward, while Workspace Security Manager secures only what already exists.
The two tools cover opposite halves of the timeline, so a complete wall uses both. Apply the wall to existing matters with Workspace Security Manager, then add a no-access entry to the client or business unit value so new matters are walled the moment they are created. Walls enforced through profile-based security do not display in Workspace Security Manager, so write down where each wall lives, or a future administrator may remove it as an error.
Role-based security testing before go-live keeps access errors out of production, and walls deserve the same test with a throwaway matter and real user accounts.
How should NetDocuments metadata fields be governed after go-live?
NetDocuments metadata fields should be governed after go-live through a written field register, a change process for new fields and values, and periodic checks on field completion. Fields drift as teams add values, and ungoverned drift erodes search.
- Field register. Record each custom field, its type, lookup table, owner, and purpose, 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, and a new field or dependency is a change like any other.
- Completion checks. Run a quarterly search for documents with empty or default values on required fields, and trace each gap to the team or integration that produced it.
Teams moving from another system should map old fields early, since an iManage to NetDocuments migration maps workspaces, metadata, and security from one model to the other.
Conclusion
NetDocuments standard vs custom metadata fields divide the work cleanly: the platform records history on its own, and your team defines the fields that give each document meaning. Keep custom fields few and purposeful, back them with lookup tables, use dynamic fields where extra detail applies to only some documents, and use profile-based security to extend walls to matters that do not exist yet. A NetDocuments rollout moves through design, configuration, migration, and training, and field design belongs at the start.
How Basla can help
Basla provides certified delivery team members for NetDocuments implementation through staff augmentation or Basla-managed delivery. Basla business analysts define metadata requirements and document field, lookup table, and dependency design. QA specialists test profiling, dynamic fields, and ethical walls with real user roles, and documentation specialists produce the field registers and user guides that keep metadata consistent 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 the difference between NetDocuments standard vs custom metadata fields?
The difference between NetDocuments standard vs custom metadata fields is who fills them in. Standard fields, such as created by and modified date, are recorded automatically, while custom fields, such as client, matter, and document type, are defined by administrators and completed by users.
Who can create custom metadata fields in NetDocuments?
Repository administrators create custom metadata fields in NetDocuments as profile attributes. Cabinet administrators then choose which fields each cabinet uses.
What are dynamic attributes in NetDocuments?
Dynamic attributes in NetDocuments are custom fields that appear on a profile only when a controlling value, such as a specific document type, is selected. They keep profiles short while capturing extra detail where it applies.
Does changing a user’s name update the Created By field in NetDocuments?
Changing a user’s name does not update the Created By field on existing NetDocuments documents. The field stores the name as text at the time of the action, so searches may need to include both names.
How many custom metadata fields should a legal department use?
A legal department typically needs four to six custom metadata fields in NetDocuments. Add more only when a field will drive search, workflow, reporting, or security.
Can custom metadata fields protect new matters behind an ethical wall?
Custom metadata fields can protect new matters behind an ethical wall through profile-based security on the client or business unit value. Pair it with Workspace Security Manager to cover matters that already exist.
*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.*