Overview

Being a digital insurance platform, Root abstracts most of the functionality required to issue and administer policies, making it easy to launch new insurance products fast. Most Root platform features are "standard" - they work out-of-the box and do not need to be configured for each individual insurance product.

At the same time, Root offers the flexibility to configure a range of platform features to meet product-specific requirements. For example, each product will have distinct rating factors, pricing logic, policy documents, and claim information requirements. Read more about which features you can configure in the product modules features guide.

On Root, the term "product module" refers to the set of configurable features that are tied to a specific insurance product. These features interact with and depend on the standard, non-configurable platform features. This is similar to how a video game interacts with a video game console, or a software application interacts with an operating system.

You can configure your product module using the Root Workbench.

Product module definition

The product module configuration that applies at a given point in time is called the "product module definition".

The product module definition acts as a factory or template for new insurance policies. When a quote is first created, it is linked to a specific product module definition. When a policy is issued from the quote, it will be linked to the same definition. This definition will determine what data are stored on the policy, as well as the behaviour of the policy over its lifecycle.

When you make changes to your product module (for example, changing the layout of the policy schedule using the Workbench CLI), this creates a new product module definition. Note: This change will only apply to policies associated with the new definition.

📘

Associating existing policies with a new product module definition

Existing policies are not automatically associated with a new product module definition. This means that different sandbox policies issued under the same product module can be associated with different product module definitions.

However, all production policies under a given product module must be associated with the same product module definition. To enforce this, we associate all existing production policies with the latest live product module definition whenever a product module definition is deployed to live.

Live vs. draft version of a product module definition

Every time a new change is pushed to a product module, this creates a new minor version of the product module definition. For example, version 1.2 will be created from version 1.1.

When draft changes to a product module are deployed to live, this creates a new major version of a product module. For example, version 2.0 will be created from version 1.2. The live version of a product module is typically the version currently used in production, while the latest draft version will contain pending changes before they are deployed to live.

The draft product module definition allows you to test any changes before they are deployed to live. You can do this by selecting "Latest draft" when you issue a new policy on the dashboard. When issuing policies via the API, you can use the draft product module definition by adding ?version=draft to the URL when getting a quote

📘

The quote determines the product module definition associated with the policy

The ?version=draft parameter can only be used on the endpoint to get a quote - not on the endpoints to create an application or issue a policy. The quote determines which product module definition (live or draft) will be associated with the application and the policy.

In sandbox mode, both the live and latest draft version of a product module can be used to issue policies. By contrast, when issuing real policies in the production environment, only the live version of a product module can be used.

This is illustrated in the diagram below. Policies A, B, C and G are production policies taken out by real customers, with real side effects. All the polices under the "Sandbox environment" column are ephemeral and used for testing only.

All policies in the production environment must be associated with the same product module definition. So, when a new product module definition is deployed, Policies A, B, C and G will be updated to the newly created product module definition version 3.0. By contrast, sandbox policies may still be associated with older product module definitions.