Frequently asked questions

There's currently not a way to append a file name after discovery but prior to publishing.

As long as the set hasn't been published, if the image reports an error, you can retry the image and/or make corrections to the native and then retry the error.

There's no official support for a custom NIST list.

Passwords on PST and OST files are bypassed automatically by Relativity.

If you publish a processing set, even documents that have an error associated with them will get a record entered in the Document object/tab, with the Control Number field populated at the very least, even if Relativity was unable to determine anything else about the document. In other words, just because a document has an error during processing doesn't mean that it won't be displayed in the Document list with a control number when you publish the processing set. The only way this doesn't happen is if the error occurs during ingestion and either Relativity is unable to extract the document from a container or the source media is corrupt.

The processing engine captures all the dates of calendar items. If there is not a field for it in Relativity, this data will end up in the "OtherProps" field.

Audio and video files are identified, but no metadata (other than basic metadata) or text is extracted from them. They will be marked as unprocessable.

When a user submits a ticket to change the processing region setting for the Relativity instance, it is best to have no processing jobs running. This setting takes effect for new jobs and impacts the results of zip file/folder name extraction, text extraction, imaging, and native viewer conversion. Contact your Customer Success Manager for more details on how changing this setting can impact your review experience.

During Discovery, native date and time information is extracted and normalized to Coordinated Universal Time (UTC) if not already stored in this format.  Processing then uses the time zone configured in the Processing Profile (and corresponding Data Sources that inherit this setting) to apply the desired UTC offset to date and time metadata fields.  These adjusted values are also reflected in the extracted text, for example, the Sent Date/Time displayed in the header portion of the email text.

In the case of emails, the Sent Date/Time value from the message header is used in the generation of the processing deduplication hash. However, this approach utilizes pre-adjusted date and time values, allowing for deduplication of emails sent and received in different time zones.

For Daylight Saving Time (DST), Relativity maintains a table that stores current and historical DST rules by location.  In this way, the appropriate DST adjustment is always applied on top of the UTC offset, given a document's specific date in combination with the selected time zone.  For example, a change to how the United States observes DST went into effect in 2007.   Relativity applies the appropriate DST adjustment, which is different for documents authored before and after 2007, provided the configured time zone falls within the United States.

Processing also utilizes the configured time zone to populate two system fields that are automatically mapped and published to the workspace: Relativity Native Time Zone Offset and Time Zone Field. These are used downstream for Native Viewer file conversion and Imaging activities.  For more information, see System-Mapped Fields.

Yes. Date/time formatting displayed in extracted text, imaging results, and the native viewer is influenced by the processing region configured for your Relativity instance. This setting typically corresponds to the geographical location of your Relativity instance, but it can be changed. Note that this setting does NOT change the display of dates and times within Document fields or elsewhere in the user interface; these are controlled by your web browser's language and localization settings. Contact your Customer Success Manager for questions regarding the processing region instance settings or browser-based localization settings.

No, there is no alteration to the processing source location. Relativity reads from this intermediate location and copies the files to the Relativity workspace file repository.

The DeNIST report displays only attachments. You can look at the INVXXXXX database in the DeNIST table to see the individual files.