NetDocuments dynamic metadata fields are profile fields that stay hidden until a user selects a particular value in another field, at which point they appear and ask for information that only applies in that context. NetDocuments calls them dynamic attributes. They let you capture detailed metadata for specific kinds of documents, such as invoices or agreements, while every other document keeps a short, quick profile.
The trade-off they solve is familiar to anyone who has designed a profile form. Every field you add helps someone and slows everyone else. This guide explains how dynamic attributes work, how to configure them, and how to test and govern them once they are live.
What are NetDocuments dynamic metadata fields?
NetDocuments dynamic metadata fields are custom profile attributes flagged as dynamic, so they remain hidden until a value in a controlling field calls for them. 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. A simple example: when a user selects Email as the document type, a hidden field can appear asking whether the email is internal or external, a question that would make no sense for other document types.
Two attributes work together to make this happen. The dynamic attribute is the conditional field itself, and it can be text, date, or backed by a lookup table, like any other custom attribute. The controlling attribute is the field whose value decides what appears, most often document type. It uses a lookup table, and each value in that table can call up its own set of dynamic fields.
Why do dynamic fields improve the NetDocuments profiling experience?
Dynamic fields improve the NetDocuments profiling experience by cutting the number of fields each user sees on a typical save. Most documents need only the core profile fields, so hiding the rest removes friction from the most common action in the system.
Form research supports this approach. Baymard Institute’s usability testing of ecommerce checkouts found that the number of form fields users must consider affects overall usability far more than the number of steps, and its recommended fix is hiding fields most users do not need behind a link that reveals them.
- Fewer fields on screen. A profile with five core fields stays at five for most documents, even if the repository captures 15 or more fields across all document types.
- Better context. Extra fields appear at the moment they apply, so users meet them when they are relevant and have less reason to skip them.
- Cleaner data. A field that appears only when it applies gets answered, while a field that is always visible and usually irrelevant gets skipped or filled with a default.
How do you create a dynamic attribute in NetDocuments?
You create a dynamic attribute in NetDocuments by defining a new profile attribute, selecting the dynamic option, noting its attribute ID, and enabling it on the cabinets that need it. A repository administrator carries out each step in the admin console.
- Create and flag. Define the attribute as you would any other, choosing its type and whether it uses a lookup table, then select the dynamic option.
- Note the ID. Every attribute has a numeric ID, and you need it to connect the dynamic field to its controlling value.
- Enable on the cabinet. Add the attribute to each cabinet where it should appear. A dynamic attribute that is not enabled on a cabinet never shows up there.
When the feature launched, it had to be enabled by NetDocuments. Confirm with your NetDocuments contact that dynamic attributes are available in your repository before you design around them.
How do controlling values trigger NetDocuments dynamic fields?
Controlling values trigger NetDocuments dynamic fields through the Type field of a lookup value, where you list the dynamic attribute IDs in curly braces. When a user selects that value, the listed fields appear in the order they are entered.
A typical setup enters four dynamic attributes as {1083}{1084}{1085}{1086} on an invoice document type, covering received date, status, reviewer, and paid date. Those IDs are illustrative, so use the IDs from your own attribute list. A single controlling value can reveal a whole group of related fields, and the sequence in braces becomes the display order, so list the IDs in the order users should complete them.
Which legal use cases suit NetDocuments dynamic fields?
Legal use cases that suit NetDocuments dynamic fields are those where one kind of document needs details that others do not. The pattern is always the same: a document type or practice value reveals a small, related set of fields.
- Invoice tracking. Received date, status, reviewer, and paid date appear only for invoices, and saved searches on status show where each invoice stands.
- Agreements. Counterparty, effective date, and expiry date can appear only when the document type is an agreement, giving the repository a light contract register.
- Litigation material. Court, case number, or filing date can appear only for pleadings or matters in a litigation practice area.
Keep each group small. Three or four dynamic fields per controlling value is usually enough, and a longer group recreates the problem dynamic fields were meant to solve.
What happens to NetDocuments dynamic field values when a field is hidden?
What happens to a NetDocuments dynamic field value when the field is hidden depends on how the attribute is configured, and the choice should be deliberate. A user may change the document type after filling in dynamic fields, and the old values either stay on the profile or are cleared.
Check the options available in your version’s attribute settings and choose per field. Clearing suits values that only make sense for the previous selection, such as an invoice status on a document that turns out to be correspondence. Keeping suits values worth preserving if the document type is later switched back, or optional details that do no harm when retained.
Test both behaviors with real documents. A stale value hidden on a profile can still appear in search results and confuse users.
How are dynamic attributes different from dependent attributes in NetDocuments?
Dynamic attributes differ from dependent attributes in NetDocuments because dynamic attributes control whether a field is visible, while dependent attributes control what value a field holds. The two are often confused with each other and with parent-child lookups, and all three solve different problems.
- Dynamic attributes. Show or hide a field based on another field’s value. The user still enters the value in the field that appears.
- Dependent attributes. Fill in a value from another field. Default from supplies a value the user can change, and Determined by supplies a locked value the user cannot edit.
- Parent-child lookups. Filter one lookup list by the value chosen in another, such as a matter list narrowed to the selected client.
The two can work side by side. A dynamic field can appear for agreements while a dependent field fills the responsible office from the author.
Can NetDocuments dynamic fields be populated during a migration?
NetDocuments dynamic fields can be populated during a migration, since dynamic attributes can be filled on import. That matters when legacy documents already carry the detail, such as invoice dates or agreement terms.
Import dynamic values only for documents whose controlling value calls for them, because a contract field on correspondence becomes hidden clutter. Clean the values first. Messy legacy data can undermine an otherwise sound platform build, and dates or statuses carried over from an old system need the same cleanup as core fields.
Teams moving platforms should plan this mapping early, since an iManage to NetDocuments migration maps workspaces, metadata, and security from one model to the other.
How do you test and govern NetDocuments dynamic fields?
You test and govern NetDocuments dynamic fields by checking every controlling value against the fields it should reveal, then recording the attribute IDs and rules in a design record. Dynamic setups depend on numeric IDs typed into lookup values, so small errors are easy to make and hard to spot.
- Test every value. Select each controlling value in profiling and search and confirm the right fields appear in the right order.
- Keep an ID map. Record which IDs each controlling value calls and why, since undocumented configuration becomes technical debt the next administrator inherits.
- Release changes. Treat new dynamic fields like any other configuration change, because configured legal platforms need a release process that tests changes before they reach users.
Conclusion
NetDocuments dynamic metadata fields let a repository capture rich, context-specific detail while keeping everyday profiling short. Build them around a clear controlling attribute, keep each group to a few fields, decide how hidden values behave, and test every controlling value before launch. A NetDocuments rollout moves through design, configuration, migration, and training, and dynamic field design fits best in the first stage, alongside the document type list that usually controls it.
How Basla can help
Basla provides certified delivery team members for NetDocuments implementation through staff augmentation or Basla-managed delivery. Basla business analysts identify where context-specific metadata adds value and document controlling values, dynamic fields, and attribute IDs. QA specialists test every controlling value across profiling and search, and documentation specialists produce the design records and user guides that keep the setup maintainable.
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 are NetDocuments dynamic metadata fields?
NetDocuments dynamic metadata fields are profile attributes that stay hidden until a user selects a qualifying value in another field. NetDocuments calls them dynamic attributes, and they keep profiles short while capturing extra detail where it applies.
What is a controlling attribute in NetDocuments?
A controlling attribute in NetDocuments is the lookup-based field whose selected value decides which dynamic attributes appear. Document type is the most common controlling attribute.
How do you link a dynamic attribute to a controlling value?
You link a dynamic attribute to a controlling value by entering the dynamic attribute’s numeric ID in curly braces in the Type field of that lookup value. Several IDs can be listed in sequence, and their order sets the display order.
Can dynamic attributes use lookup tables?
Dynamic attributes in NetDocuments can use lookup tables, and they can also be text or date fields. They are created like any other custom attribute, with the dynamic option selected.
What is the difference between dynamic and dependent attributes?
Dynamic attributes control whether a field is visible, while dependent attributes control what value a field holds. Dependent attributes use Default from for an editable value or Determined by for a locked one.
Can dynamic attributes be populated when importing documents?
Dynamic attributes can be populated when importing documents into NetDocuments. Import values only for documents whose controlling value calls for those fields.
*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.*