RSMF field reference

The Relativity Short Message Format (RSMF) stores normalized short-message data in a single, searchable file. Sources include chats from Microsoft Teams, Slack, Google Chat, and mobile sources collected through Cellebrite/Universal Forensic Extraction Device Report (UFDR). When you process an RSMF file, Relativity extracts its headers and metadata, and maps them to workspace fields you can search, sort, filter, and produce on.

RSMF field mapping process

This section explains how data moves from the file a converter produces, through Relativity's processing discovery, to the mappable fields you see in the Field Catalog. Understanding this pipeline helps you anticipate which fields are available for a given source and how to map them correctly during processing.

Anatomy of an RSMF file

An RSMF file is an RFC 5322-compliant (email-style) message with two nested levels:

• Message headers—a set of X-RSMF-* headers on the outer message that summarize the file (version, date range, source application, participants, and counts). X-RSMF-Version is required and must appear first.
• rsmf.zip—a single attachment on the message that holds everything else:
  • rsmf_manifest.json—the required manifest at the root of the zip; the structured body that describes participants, conversations, and events (individual messages, along with their reactions, edits, and attachments).
  • Referenced files—the attachments, avatars, and platform icons named in the manifest.

From RSMF file to workspace field

RSMF data reaches a mappable Relativity field in three stages:

1. Conversion or collection writes the file. Each converter, such as Microsoft Teams, Slack, Cellebrite/UFDR, or Google Chat, populates the RSMF headers and manifest. A converter sets only the fields that apply to its source, so field coverage varies by source. See Source coverage.
2. Processing discovery extracts the headers. Relativity reads each X-RSMF-<Name> header and produces an extracted‑metadata entry named Rsmf/<Name>. Recognized headers are given typed, friendly fields (for example, X-RSMF-EventCount becomes the message‑count field and X-RSMF-BeginDate becomes a date field). A header that Relativity does not specifically recognize is still captured as Rsmf/<Name>.
3. Field mapping surfaces the data. Discovered RSMF fields appear in the Field Catalog under names such as RSMF Application, RSMF Message Count, RSMF Participants, and RSMF Version. You map these to workspace fields the same way you map any processing field. An extracted value that you do not map to a field is still available through the Other Metadata field. See Known issues and limitations.

Manifest contents

The manifest body is what the Short Message Viewer renders, and it drives how a conversation is displayed. At its root the manifest requires version, participants, conversations, and events, plus an optional eventcollectionid. The main objects are:

Object	Fields	Purpose
Attachment	id(required), display, size	A file referenced from an event; id matches a filename in rsmf.zip.
Conversation	id(required), platform(required), participants(required), display, type, custodian, icon, custom	A time-bound set of events on one platform. type is direct (fixed participants) or channel (participants may enter and leave).
Edit	participant(required), timestamp, previous, new	A change made to an event's body.
Event	type(required), id, conversation, participant, timestamp, body, parent, deleted, importance, direction, reactions, attachments, edits, read_receipts, custom	A single item in a conversation, usually a message.
Participant	id(required), display, email, account_id, avatar, custom	A person in a conversation. account_id holds a phone number or platform handle where one is available. At least one participant is required.
Reaction	value(required), count, participants	An emoji or reaction applied to an event.
Read receipt	participant(required), timestamp, action	Delivery or read status for an event (delivered or read).

The RSMF 2.0 event type values are message, disclaimer, join, leave, history, and unknown. A source event type that has no direct RSMF equivalent (for example, a Microsoft Teams Media_CallRecording) is written as an unknown event and flagged as a placeholder. See Known issues and limitations.

RSMF header fields

The following X-RSMF-* headers summarize an RSMF file and become searchable metadata during processing. RSMF fields are not pre-defined in the processing Field Catalog. They are discovered from the headers when you process RSMF data, then become available for mapping. The names below are the discovered field names as documented on the Mapping processing fields page. The exact set you see depends on which headers are present in your data.

RSMF header	Discovered field name	Description and format	Notes and limitations
X-RSMF-Application	RSMF Application	Identifies the source application. Typical values: Teams; Slack; Cellebrite - <platform> (for example, Cellebrite - WhatsApp, Cellebrite - SMS/MMS); and the Google Chat application name.	Best single indicator of the source app, but it does not reliably distinguish every underlying platform. See Identifying the original data source.
X-RSMF-AttachmentCount	RSMF Attachment Count (key Rsmf/AttachmentCount)	Total number of attachments across all events (whole number).
X-RSMF-BeginDate	RSMF Begin Date (key Rsmf/BeginDate)	ISO 8601 time stamp of the earliest event in the file.	Used as a fallback Sent Date. Not available as an inventory date-range filter. See Known issues and limitations.
X-RSMF-Custodian	RSMF Custodian	Intended to identify the custodian the data was collected from.	Recognized when present (for example, in externally built RSMF files) but not written by the Microsoft Teams, Slack, Cellebrite/UFDR, or Google Chat converters, so it is typically empty for RSMF that Relativity generates. Use the processing set's custodian assignment instead.
X-RSMF-DuplicatedEventCount	(discovered as Rsmf/DuplicatedMessageCount)	Count of events identified as duplicates during conversion.	Cellebrite/UFDR only. Note the extracted key is Rsmf/DuplicatedMessageCount, not …EventCount.
X-RSMF-EndDate	RSMF End Date (key Rsmf/EndDate)	ISO 8601 time stamp of the latest event in the file.	Used as a fallback Last Modified date. Same inventory date-range filter limitation as Begin Date.
X-RSMF-EventCollectionID	RSMF Event Collection Id	A shared ID that keeps multiple RSMF files from one conversation grouped together for sorting. Also present as the manifest root property eventcollectionid.	Used when a single conversation is split across more than one RSMF file.
X-RSMF-EventCount	RSMF Message Count (key Rsmf/MessageCount)	Number of message events in the file (whole number).
X-RSMF-Generator	RSMF Generator	Identifies the tool that authored the RSMF file.	Most relevant for externally built RSMF files; may be empty for some Relativity converters.
X-RSMF-HasPlaceholders	(discovered as Rsmf/HasPlaceholders)	Present with the value true when the file contains placeholder events created for unsupported event types. Each placeholder event also carries a custom is_placeholder = "true" value.	Produced by the Microsoft Teams converter only. See Known issues and limitations. Not produced by Slack, Cellebrite/UFDR, or Google Chat.
X-RSMF-MissingAttachmentCount	(discovered as Rsmf/MissingAttachmentCount)	Count of attachments that events reference but that are not present in rsmf.zip.	Written by the Slack,Cellebrite/UFDR, and Google Chat converters.
X-RSMF-Participants	RSMF Participants (key Rsmf/Participants)	The participants in the conversation. Stored as a single comma-separated string in the manifest.	Discovered as Multiple Choice, so it displays semicolon-delimited rather than with the manifest's commas. This is expected, not data loss. Map as Long Text for best performance.
X-RSMF-Version(required)	RSMF Version	The RSMF specification version the file conforms to (for example, 2.0.0).	Always present; required for a valid RSMF file.
Custom X-RSMF-<Name>	(discovered as Rsmf/<Name>) → Other Metadata	Any custom header added in the X-RSMF-* namespace (for example, X-RSMF-Chat-ID, X-RSMF-Room-ID, X-RSMF-Conversation-Type).	Captured as extracted metadata. If you do not map it to a field, its value appears in the Other Metadata field. A custom header not in the X-RSMF-* namespace is retained only inside the raw Email/MessageHeader field. See Known issues and limitations.

All RSMF fields are discovered from headers, and not predefined in the Field Catalog. The named fields above (RSMF Version, RSMF Application, and so on) are the fields documented on the Mapping processing fields page. Other X-RSMF-* headers are discovered as Rsmf/<Name> and surface through the Other Metadata field if you do not map them.

Source coverage

Different converters populate different optional fields. Use this matrix to compare what to expect in RSMF output across data sources.

Field	Microsoft Teams	Slack	Cellebrite / UFDR	Google Chat
X-RSMF-Application	✓ (Teams)	✓ (Slack)	✓ (Cellebrite - <platform>)	✓ (Google Chat)
X-RSMF-BeginDate / EndDate	✓	✓	✓	✓
X-RSMF-Custodian	—	—	—	—
X-RSMF-DuplicatedEventCount, X-RSMF-Chat-ID	—	—	✓	—
X-RSMF-EventCollectionID	✓	✓	✓	✓
X-RSMF-HasPlaceholders	✓	—	—	—
X-RSMF-MissingAttachmentCount	—	✓	✓	✓
X-RSMF-Participants	✓	✓	✓	✓
X-RSMF-Room-ID, X-RSMF-Conversation-Type	—	—	—	✓

Legend: ✓ = populated by this source's converter, — = not populated

Identifying the original data source

RSMF does not include a dedicated field that identifies the original source type of a converted document, for example, distinguishing WhatsApp from SMS, or a chat export from a plain text file. X-RSMF-Application is the closest indicator, but it reflects the converting application rather than a guaranteed, normalized source-type value.

If source-type identification matters for your matter, use one or more of these approaches:

• Processing profile—each profile is configured for a specific data source, so the source type is inferable from which profile produced a given RSMF document.
• Custodian and folder structure—if data from different sources is separated into distinct processing sets, the workspace folder location or custodian assignment can serve as a source indicator.
• File-naming conventions—some collection tools include source identifiers in the extraction filenames, which carry through to RSMF output.

If source-type identification is a requirement, document the source-to-profile mapping before processing begins. It is difficult to reconstruct reliably afterward.

Known issues and limitations

The following known issues affect RSMF field mapping:

• Participants field appear with semicolons after loading into Relativity.
  In the RSMF manifest, X-RSMF-Participants is a single comma-separated string. Relativity discovers the field as Multiple Choice (a multi-value field) and renders it using its multi-value delimiter (a semicolon). The delimiter you see therefore differs from the manifest's comma. This is expected field-type behavior, not a conversion error, and the participant values themselves are unchanged. The field is RSMF Participants (extracted key Rsmf/Participants). There is no separate M-EDS-Participants field. To maximize performance, map RSMF Participants as Long Text.
• Custom X-RSMF-* header values appear in Other Metadata when they are not mapped.
  Any custom header in the X-RSMF-* namespace is extracted as Rsmf/<Name>. If you have not mapped that field, its value is surfaced through the Other Metadata field, where names and values are delimited by semicolons. To capture a custom header in its own dedicated field, add it to your field mapping before processing. A custom header that is not in the X-RSMF-* namespace is retained only inside the raw Email/MessageHeader field and does not become its own extracted field.
• Begin Date and End Date cannot be used to filter by date range in inventory.
  X-RSMF-BeginDate and X-RSMF-EndDate populate the RSMF Begin Date and RSMF End Date fields and act as fallback Sent Date / Last Modified values, but they are not available as an inventory date-range filter. To narrow an RSMF population by date, filter after publish using the mapped date fields.
• Placeholders are created for unsupported Microsoft Teams event types.
  When the Teams converter encounters an event type that has no direct RSMF equivalent, it writes the event with the unknown RSMF type and marks it as a placeholder, so the item is not silently dropped. Known unsupported Microsoft Teams event types include Media_CallRecording, Media_Card, Media_CallTranscript, RoleUpdate, TopicUpdate, and SpaceTopicUpdated. Any other unrecognized event type is handled the same way. When a file contains at least one placeholder, the converter sets X-RSMF-HasPlaceholders = true, and each placeholder event carries a custom is_placeholder = "true" value. This mechanism applies to the Microsoft Teams converter only. Slack, Cellebrite/UFDR, and Google Chat do not create placeholders.
• The Short Message Viewer displays only what is present in the manifest.
  The viewer cannot infer data that a converter or external builder did not include. If reactions, edits, or read receipts are missing from the manifest, they do not appear in the viewer and cannot be populated retroactively after ingestion. Similarly, attachment rendering depends on exact, case-sensitive filename matching between the manifest and rsmf.zip.

Resources

The following pages provide related information:

• The Relativity Short Message Format
• Mapping processing fields
• Working with RSMF files built outside of Relativity
• Processing an RSMF file
• Short Message Viewer