The Only 6 Metadata Fields Most Teams Actually Need for Email Records

When teams start managing emails in SharePoint, metadata can quickly become more complicated than it needs to be.

A new library may begin with a few sensible columns. Over time, more fields are added for departments, categories, document types, status, confidentiality, retention, regions and other details. Soon, users are presented with a long form every time they save an email.

The problem is not that these fields are useless. The problem is that most of them are not useful for every email.

We have previously explained the broader role of metadata in Email Metadata in SharePoint, including why the information recorded by SharePoint during upload may not accurately represent the original email.

Here, we look at a more practical question: which metadata fields do most teams genuinely need?

For many organisations, six well-chosen fields are enough to make saved emails easy to find, filter and understand:

1. From
2. To
3. CC
4. Subject
5. Sent or received date
6. Client, project or matter

The first five already exist within the email and should be captured automatically. Only the final field usually requires input from the person saving it.

Why fewer metadata fields often work better

A detailed metadata structure may look impressive during planning, but it can create problems once employees begin using it.

If people have to complete ten or fifteen fields every time they save an email, they may:

• Skip fields
• Select the first available option
• Enter inconsistent information
• Save the email somewhere else
• Avoid saving it altogether

This leaves the organisation with more metadata fields but less reliable information.

A better approach is to begin with the details people genuinely use when searching for an email. In most cases, they want to know:

• Who sent it?
• Who received it?
• Who else was included?
• What was it about?
• When was it sent?
• Which client, project or matter does it belong to?

These questions lead directly to the six most useful fields.

1. From

The From field identifies the original sender of the email.

This sounds straightforward, but it is important to distinguish the email sender from the person who saved the message to SharePoint.

For example, suppose a client emails Kate on 10 July, and Kate saves the message to SharePoint two days later. SharePoint may record Kate as the person who created or uploaded the file. That does not mean Kate sent the original email.

A dedicated From column preserves the actual sender and allows users to filter records by the person or organisation that initiated the message.

This is particularly useful when looking for:

• Instructions received from a client
• Correspondence from a supplier
• Messages sent by a regulator
• Approvals provided by a manager
• Requests received through a shared mailbox

Shared mailboxes can introduce additional challenges when preserving the original sender and recipient information. If your team manages customer enquiries or support requests from shared inboxes, see How to Save Shared Mailbox Emails to SharePoint Without Forwarding for a simpler approach that keeps the original email details intact.

The From value should be extracted from the original email rather than entered manually.

2. To

The To field shows the primary recipients of the email.

It helps users understand who was directly addressed and which person or team was expected to respond or act.

For instance, an email sent to a project manager may have a different significance from one sent to a general enquiries mailbox, even when the subject is similar.

A searchable To column can help answer questions such as:

• Was the email sent to the accounts team?
• Did the client send the instruction to the correct person?
• Which shared mailbox received the request?
• Was the message directed to an individual or a wider group?

Recipient information can be difficult to search when it is stored only inside the email file. Capturing it as metadata makes it available directly within the SharePoint library.

3. CC

People included in CC may not be the primary recipients, but their involvement can still matter.

The CC field can show who was informed, who had visibility of a decision and which departments were included in a conversation.

This becomes particularly useful during a review, dispute or audit. A team may need to confirm whether a manager, legal adviser, finance representative or client contact was copied on an important message.

CC should be kept separate from To. Combining them into one recipient field removes the distinction between the person expected to act and someone included for information.

For a closer look at configuring these recipient details correctly, see How to Capture From, To and CC Reliably as SharePoint Columns.

4. Subject

The Subject field provides a quick indication of what the email is about.

Even when a saved email has a clear file name, retaining the original subject is useful. It allows users to search for familiar wording from Outlook and identify messages from the same conversation.

If your team regularly files entire email threads rather than individual messages, see How to Save a Conversation to SharePoint for guidance on preserving complete conversations while maintaining useful metadata.

However, subject lines are not always reliable on their own. Emails called “Update”, “Quick question” or “Re: Final version” provide very little context once they are separated from the inbox.

That is why the subject should be captured as metadata but should not be expected to do all the work. The other fields provide the people, date and business context needed to identify the correct record.

5. Sent or received date

The original email date is one of the most important fields to preserve.

A common mistake is to rely on SharePoint’s Created date. This normally shows when the email was added to the library, not when the communication actually took place.

Consider this example:

• The client sends an approval on 10 July.
• An employee saves it to SharePoint on 15 July.
• SharePoint displays 15 July as the Created date.

If the original email date is not captured, the record may appear to be five days newer than it really is. This can distort the timeline and create confusion during a review.

The metadata should therefore preserve the original Sent or Received date, depending on how the library and filing process are configured.

This allows teams to arrange email records in the order the communication occurred, rather than the order in which employees saved them.

6. Client, project or matter

The first five fields describe the email itself. The sixth explains where it belongs within the business.

Depending on the organisation, this field may be called:

• Client
• Project
• Matter
• Case
• Contract
• Account
• Claim

This is usually the most valuable user-selected field because it connects the email to the work it supports.

An email subject may change during a long conversation. Different people may join or leave the thread. The same client may also have several active projects. A consistent client, project or matter field gives all related correspondence one shared reference.

This field should ideally use a controlled list rather than free text. Otherwise, one employee may select “ABC Limited”, another may enter “ABC Ltd”, and a third may simply write “ABC”. These variations make filtering and reporting less reliable.

The options should also be limited to values relevant to the user or team wherever possible. Asking someone to search through hundreds of unrelated projects whenever they save an email adds unnecessary friction.

Which fields should be captured automatically?

The email already contains:

• From
• To
• CC
• Subject
• Sent or received date

Users should not have to type this information again. Manual entry takes time and can introduce spelling mistakes, missing recipients and incorrect dates.

These five properties should be extracted from the original email and mapped to the appropriate SharePoint columns. The person saving the email should normally only need to select the client, project or matter.

Tools such as Konnect eMail can extract email properties and add them to mapped SharePoint metadata fields as the email is saved from Outlook. This helps preserve the original email information without asking employees to re-enter details that are already available.

What about document type, status and retention fields?

Some teams genuinely need additional metadata. A legal team may need a correspondence type. A finance team may need an invoice reference. A records team may need a retention category.

These fields should be added only when they support a specific process, search requirement or governance rule.

Before adding another required field, ask:

• Will people regularly search or filter by it?
• Can its value be applied automatically?
• Does it support a defined compliance requirement?
• Will users understand what to select?
• Is the information already available somewhere else?

If the field does not have a clear purpose, it may not need to be part of the email-saving process.

Optional fields can also be shown only to the teams that need them. There is little value in asking every employee to complete a field used by one department.

Test the six fields using real searches

The best way to check a metadata structure is to test it with questions employees might ask later.

For example:

• Show me emails received from this client last month.
• Find the approval sent to the project manager.
• Show all correspondence where the legal team was copied.
• Find emails relating to Project Alpha.
• Arrange the client’s emails in their original date order.
• Search for messages with “contract renewal” in the subject.

If the six fields allow users to answer these questions, the metadata is doing its job.

If an important search cannot be completed, consider whether one additional field is needed. Build the structure around genuine retrieval needs rather than every possible way an email could be classified.

Keep email filing simple enough to use

Metadata should make email records easier to manage, not make saving them more difficult.

For most teams, From, To, CC, Subject, Sent or Received Date, and Client, Project or Matter provide enough information to find and understand an email later. Five of these fields already exist in the message and can be captured automatically, leaving the user to add only the relevant business context.

Konnect eMail helps teams save emails and attachments from Outlook to SharePoint, Teams and OneDrive while capturing key email properties as metadata. This reduces manual entry and helps organisations create a filing process employees can realistically follow.

The most effective metadata structure is rarely the one with the most fields. It is the one that captures the right information consistently.