RelativityOne release process

RelativityOne customers rely on our platform to handle vast amounts of complex data within tight deadlines, while adhering to quality, legal, and procedural requirements. We recognize the critical nature of your work and the indispensable need for RelativityOne to meet availability and reliability standards. At the same time, we are committed to delivering our latest innovations once they meet rigorous criteria, enabling you to enhance efficiency and leverage AI capabilities for faster and superior outcomes. Our release process is designed around a balanced approach to ensuring both a reliable and stable platform as well as a rapid innovation pipeline. These processes follow SaaS industry best practices, and we have adopted technologies and release frameworks that ensure you can benefit from our latest innovation and improvements in a safe and timely manner.

Key Concepts

Note: These concepts are applicable for both RelativityOne and RelativityOne Government
  • Release timing – New features and enhancements are almost exclusively delivered via zero downtime deployment pipelines. Release timing is generally determined on a change-by-change basis, and we aim to minimize potential impacts to your workflow through release timing and/or change control considerations.
  • Off-cycle changes – Changes that have low or no material impact on standard workflows and user experiences are released when ready. Many of these changes are documented in our release notes, but we generally do not provide advanced notice prior to release.
  • Monthly Packaged Release – To provide visibility and predictability into changes that have greater impact on workflows and user experience, we hold some updates for inclusion in our Monthly Packaged Release (MPR). While MPR changes are still delivered via our zero downtime deployment pipelines, rollouts are initiated within a 3-day window. MPR changes are always highlighted in the top section of our Monthly Release Email which you receive about 2 weeks before the MPR release window opens.
  • Monthly Extended Downtime Window – On a monthly basis, we upgrade the base Relativity platform during your Monthly Extended Downtime Window. (Note that Monthly Packaged Releases are separate from our Monthly Extended Downtime Window.) With rare exception, the extended downtime windows only include low level Relativity platform maintenance updates. The downtime calendar should not be considered as a release schedule for new features and enhancements.
  • Phased rollouts – Most of our changes (MPR and off-cycle) are gradually rolled out to RelativityOne production instances over a period of days or weeks. Because each rollout has different promotion criteria, we do not communicate instance-level schedules for each change. We always identify MPR changes that are planned for phased rollout, and you can find more information on our approach to phased rollouts in the FAQ below.

General Release Categories

The table below outlines expectations for the three basic categories of releases: Off-cycle Changes, Monthly Packaged Release, and Monthly Extended Downtime Window

    Off-cycle Changes Monthly Packaged Release (MPR) Monthly Extended Downtime Window
Release Content and Timing Types of Changes Product quality improvements (changes, fixes, small enhancements) New features and changes that materially augment or change workflows or product experience Lower-level platform changes
Release Timing Any time During 3-day MPR window communicated in the Monthly Release Email Extended downtime windows
N Product Changes per Month Hundreds 2 to 8 Very few
Zero Downtime Deployments? Yes Yes No
Phased rollouts? Yes Yes Yes, according to Extended Downtime Windows
Available in Sandbox before Production?
Note: Sandboxes are not currently available in RelativityOne Government
 Occasionally, but not according to standard timing or criteria. Yes, with exceptions (e.g. features with separate pricing terms such as aiR for Review and Data Breach Response). Exceptions will be noted in the Monthly Release Email  
Pre-Release Communications Advanced Notice via the Monthly Release Email No Yes (around 2 weeks before MPR window) Yes, according to the Sandbox extended downtime windows calendar
Tailored Communications We develop tailored communications plans for any changes with significant impact or that require customers to take action prior to release. These communications are generally delivered via email.
Delays N/A For delayed MPR changes that were already released to sandboxes, we will make note of any production release delays on the What’s new in RelativityOne Sandbox page. For MPR delayed changes that do not go to sandboxes, we will generally not proactively notify customers, and you can expect an update in the next Monthly Release Email. N/A
Breaking Changes Breaking changes are communicated via targeted emails and/or on the Relativity Developer Group section of our Community Site no later than 90 days before production release.
Post-Release Communications Release Notes Sometimes (if minimum workflow or user experience criteria met) Always Rarely
In-app What’s New notifications/
What's New page in Documentation		 Occasionally Always Rarely

The diagram below illustrates the Release Process for RelativityOne:
Release process diagram

Frequently Asked Questions

General questions

If you are not currently subscribed to our Monthly Product Update emails and wish to receive them, please register using this form.

We classify all changes based on level of workflow impact during an internal stakeholder review process. Any change that we determine may have a material impact on workflows or product experience for most RelativityOne customers are held for an MPR. We emphasize "most customers” because we recognize that changes may impact some customers differently based on how they use the product or design their workflows. Determining whether a change impacts our customers’ most common and standardized use cases and workflows is a key consideration for making off-cycle versus MPR decisions.

Relativity has a robust set of tools that help us quickly spot any issues with new updates we have pushed into production. In the rare case an update could cause an unexpected issue in your environment, we can swiftly roll back the changes. When this happens, we will let you know in our release notes or through our in-app notifications.

We employ ample manual and automated measures to help ensure release quality:

  • Automated local, unit, functional, and integration tests are executed on top of our Continuous Integration/Continuous Deployment (CI/CD) platform.
  • Monthly manual regression testing of the full RelativityOne platform.
  • Targeted internal user testing (“bug bashes”) for changes that meet minimum workflow or technical scope of impact thresholds.
  • Rigorous environment promotion process that evaluates change quality throughout internal and external release progression.
  • Automated rollbacks based on purpose-built criteria for each change.
  • Some new features and changes are evaluated and hardened through limited availability “Advanced Access” programs prior to being released to all RelativityOne production instances.
  • Talk to your account team – Your Relativity account team can help provide additional insights into what changes may be coming to RelativityOne in the near-term.
  • Relativity Ideas page – The Ideas page on our Community Site provides a select view of features and enhancements we are considering building. It is not an exhaustive backlog or roadmap, but provides some insight into what may be coming soon.
  • Advanced Access programs – Relativity invites a select group of customers to use and provide feedback on some new features and changes before they are released to all RelativityOne customers. Reach out to your Relativity Account Team for more information on Advanced Access programs and upcoming opportunities.

Phased rollouts

A phased rollout is when we release a new capability to specific groups of tenants at different times in order to optimize the customer experience.

MPR changes that are being rolled out in phases will be identified in the Monthly Release Email and release notes.
Off-cycle changes that are being rolled out in phases will be identified in release notes.

We publish documentation when it first begins to release to customer instances with a clarification that it is a phased rollout; release notes will also indicate if it is a phased rollout.

While we may do this for especially high impact changes undergoing a phased rollout, we generally do not send additional targeted communications to notify you when the change is about to be released to your instance. If targeted follow-up communications are planned, we will indicate this in the Monthly Release Email.