Document metadata: design the fields once, and let them do the work
A few well-chosen fields drive search, folders, file names, permissions and retention. Here is an HR department designed field by field, with where every value comes from.
Ademero Team5 min read
Metadata is the handful of values stored with each document: its type, the employee or vendor it belongs to, a date, a number. Get those few fields right and search, folders, file names, permissions, retention and reports all work from them. Get them wrong and people go back to folders called Misc 2. This guide designs one department’s fields from scratch, so you can do the same for yours.
Every field must answer three questions
- Who searches by it, or what rule uses it? If nobody searches by a field and no rule reads it, do not add it.
- Where does the value come from? Read from the page, looked up in another system, set by the system, or typed by a person. Typed should be the last resort.
- What are the allowed values? Free text for names and numbers; a fixed list for anything people would otherwise spell five ways.
Worked example: an HR department
A 300-person company wants its personnel files out of cabinets. HR handles six document types: Offer Letter, Form I-9, Form W-4, Benefits Enrollment, Performance Review and Separation Notice.
Step 1: the fields
| Field | Type | On which documents | Where the value comes from |
|---|---|---|---|
| Employee ID | Text, required, shared by all six types | All | Read from the page, or looked up from the name |
| Employee Name | Text | All | Looked up from the Employee ID |
| Department | Choice list | All | Looked up from the HR system |
| Document Date | Date, required | All | Read from the page |
| Review Period | Choice list (2025 H1, 2025 H2...) | Performance Review | Read or picked |
| Separation Date | Date | Separation Notice, Form I-9 | Typed once by HR when someone leaves |
Six fields. That is enough, because each one has a job.
Step 2: what each field powers
| Field | Search | Folders and file names | Permissions | Rules and retention |
|---|---|---|---|---|
| Employee ID | One search returns the whole file | File name starts with it | Ties the six types into one employee file, and shows what is missing | |
| Department | Filter | Folder level | Each department head sees only their own people | |
| Document Date | Date range | File name | Retention clock for most types | |
| Separation Date | Starts the I-9 retention calculation |
The resulting folder path is HR / Department / Employee Name, and a file name looks like E10482_Performance Review_2025-07-15.pdf. Nobody types either; both are built from the fields.
Step 3: a fixed list where people would improvise
The old cabinets used “Acctg”, “Accounting” and “A/P” for the same team. Department becomes a choice list filled from the HR system, so the value matches the org chart and changes there flow through. The same goes for anything with a known set of answers: document type, region, review period.
Step 4: completeness you can see
Because every document carries the Employee ID, the system can show each employee’s file as complete or incomplete against a list of required types. A new hire with an offer letter and a W-4 but no I-9 shows up on a report on day three, not at the next audit.
Getting values in without typing
- Read from the page. For paper, CapturePoint 6 recognizes each document’s type and reads its fields on the PC next to the scanner, then names the file from them. It learns from corrections, so the same layouts need less checking over time.
- Look it up. Type or read one value, such as Employee ID, and fill the rest from the system that owns them.
- Type it once for a stack. When scanning one employee’s paperwork, enter the ID once and let every document in the stack carry it.
- Let the system set it. Dates added, who added it, and the workflow stage need no one.
Keeping it clean
- Required means required. A document missing its key field should wait in a queue for someone to complete it, not be filed half-indexed.
- Check for duplicates on entry. The same invoice number from the same vendor twice is a warning, not a second document.
- Review the lists twice a year. Retire values nobody uses; merge near-duplicates.
- Give each catalog an owner. The person who answers “can we add a field?” and says no most of the time.
Mistakes to avoid
- Twenty fields “in case”. Every extra required field is a reason to skip filing.
- Keywords instead of fields. A free-text keyword box fills with noise. Use a field with a list.
- Private values in file names. Social Security numbers and account numbers belong in a protected field, not in a name anyone browsing the folder can read.
- Different names for the same field. If Employee ID is called Emp No on one type, cross-type search breaks.
How Ademero handles it
In Content Central, each catalog has document types with their own index fields: text, numbers and dates, choice lists (including cascading lists and lists filled from a database or your accounting system), required and conditionally required fields, duplicate checks and line-item tables. Global fields are shared across document types, which is what powers whole-employee search and packets that show complete or incomplete. Folder paths and file names are built from field values and can be rebuilt later if you change the pattern. Access can be limited by a field value, and retention runs per document type. Documents captured without their fields wait in a Coding Queue until someone completes them.
