Feedback
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
The following list briefly describes the important concepts of the RelativityOne release process.
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.
- 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.
- 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 three-day window.
- MPR changes are always highlighted in the top section of our Monthly Release Email which you receive about two 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. The MPR is 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.
- Since 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. For more information about phased rollouts, see the FAQ.
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, and small enhancements. | New features and changes that materially augment or change workflows or product experience. | Lower-level platform changes. |
| Release timing | Any time | During three-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? Sandboxes are not currently available in RelativityOne Government | Occasionally, but not according to standard timing or criteria. | Yes, with exceptions. For example, 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 with the Monthly Release Email | No | Yes, around two weeks before MPR window. | Yes, according to the Sandbox extended downtime windows calendar. |
| Tailored xommunications | 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 through targeted emails and 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 following diagram illustrates the release process for RelativityOne: 
Frequently asked questions
General questions
How can I subscribe to the Monthly Release Email?If you are not currently subscribed to our Monthly Product Update emails and wish to receive them, please register using this form.
How does Relativity determine what is released off-cycle versus as part of an MPR?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.
What happens when Relativity rolls back a change?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.
What is Relativity’s approach to testing and quality assurance?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, or 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.
How can I get visibility into upcoming changes beyond and in addition to what is featured in the Monthly Release Email?- 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
What is a phased rollout and why does Relativity use 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.
How will I know if a feature is part of a phased rollout?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.
Why am I seeing documentation about a capability that isn't in my instance?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.
Will Relativity send follow-up communications when a phased rollout change is about to be released to my instance?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.
