Product modules overview

Understand which features you can configure for your product module, and how they relate to standard platform features


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.

On Root, the term "product module" refers 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.


Root platform overview

Product modules are configured using the Root Workbench. Workbench comprises two tools:

  • Workbench Dashboard - A user interface on the Root management dashboard for managing product modules and viewing important product module information.
  • Workbench CLI - A low-code CLI tool for making changes to product modules and pushing them to Root.

Product module definition

The actual configuration of a product module at any point in time is called the "product module definition". For example, if you change the layout of the policy schedule, you are updating the product module definition.

The product module definition acts as a factory or template for insurance policies. A new policy will be linked to the product module definition in place at the time the quote was first created. The policy data and the behaviour of a policy over time is determined by the product module definition linked to that policy.

For example, consider the following scenario:

  1. You issue Policy A.
  2. You change the logo on the policy schedule template.
  3. You issue Policy B

In this case Policy A will still be associated with the old product module definition, and the logo on this policy's schedule will not automatically be updated to match that of Policy B. A "bump" will be required to ensure all existing policies point to the latest product module definition.

Some configurable features, such as email and SMS templates, as well as data export templates, are not associated with a specific product module definition. Updates to these features will automatically apply to both new and existing policies.

Configurable features

This section provides an overview of the features that can be configured for each individual product module. Some features are optional.

Overview of configurable vs. standard features

When building or updating configurable features, it is important to keep in mind how these features interact with standard platform features. The table below distinguishes between examples of configurable and standard features in different domains (it is not an exhaustive list of all available features).

DomainConfigurable features (examples)Standard features (examples)
Policy issuing flow
Includes creating a quote, adding a policyholder, creating an application and issuing a policy
- Rating factors
- Pricing logic
- Quote input form (schema)
- Application input fields
- Application input form (schema)
- Custom policy fields (module object)
- Policy charges
- Creating a policyholder (customer onboarding)
- Adding a payment method
- Adding beneficiaries
- All dashboard workflows (except quote and application schemas)
- Standard policy fields
Policy documents
The documents sent out to policyholders containing policy information
- Policy schedule
- Terms file
- Quote summary
- Welcome letter
- Anniversary letter
- The set of supported document templates
- Which document templates are required vs. optional
Administering existing policies
Viewing and making changes to policies that have already been issued
- Making customer initiated changes to policies (alteration hooks)
- Reactivating policies
- General dashboard layout and workflow
- Dashboard policy view
- Cancelling policies
- Complaints
- Adding notes to a policy
- Uploading documents to a policy
Automated actions for existing policies
Configuring the platform to make automated changes to policies or perform other actions related to policies
- Lapse rules and other policy lifecycle rules
- Automated actions that run on a fixed schedule (e.g. anniversary logic)
- Automated actions that are triggered by policy lifecycle events (e.g. custom logic to lapse policies when a payment fails)
- Policy expiration at end date
The information saved against claims, and the Dashboard workflow from opening to finalising a claim
- Claim information parameters
- Claim document labels
- Claims assessor checklist
- Payout and fulfillment requests
- Five-step claim workflow
- Capturing claimant information
- Capturing beneficiary details
- Claim assessment workflow (except assessor checklist)
- Assessment confirmation workflow
Email and SMS communications sent to policyholders
- Email templates
- SMS templates
- Enabling / disabling individual communication events
- List of supported communication events
- The attachments included with each communication event
Determining the amount due on a policy and performing the collection
- Billing frequency (monthly or yearly)
- Enabled payment method types (debit order, card payments, EFTs, external payment methods)
- Enabling / disabling pro rata billing for policy issuing
- Debit order settings (e.g. how to handle weekends, whether to retry payments, etc.)
- Refunds
- Payment coupons
- Raising of policy premiums by the platform
- Ad hoc collection requests and payments
- Billing day adjustments and pro rata calculations from this post successful payment being received.
Data exports
Exporting policy and other data for external consumption
- Custom policy fields
- Which fields to include in each data export template
- Filters
- Basic data manipulation using handlebars
- Supported data sources (e.g. policies, policyholders, payments, claims, etc.)
- Data objects included in each data source
API docs
Reference documentation for API endpoints
- Documentation for product-specific endpoints like the quote hook, application hook and alteration hooks- Documentation for standard Root endpoints like creating a policyholder or adding a payment method


Configured using: Workbench CLI
Changes automatically apply to existing policies: No

Root allows you to configure basic product setup and some product features as simple settings. These settings relate to features that are generally relevant to all types of insurance products, and are simple enough that they don't need to be configured using code.

There are two types of settings:

  • General settings - These settings relate to basic product setup and general features.
  • Billing settings - These settings are used to configure some of the basic billing rules for your product.

Event hooks

Configured using: Workbench CLI
Changes automatically apply to existing policies: No

Event hooks are blocks of code - typically JavaScript functions - that are used to configure product-specific functionality. They give you the ability to easily inject custom logic into certain events on the platform. This enables you to intercept and modify the platform's standard behaviour.

Event hooks can be triggered in one of two ways. Some hooks are triggered by user initiated API calls, such as making call to the quote endpoint to get a quote. In configuring these hooks, you will customise how certain Root API endpoints will function for your product.

Other hooks are triggered by predefined events in a policy's lifecycle, such as a claim being approved or a premium collection attempt failing. Scheduled functions can also be defined to run at specified time intervals.

Event hooks can be used to configure the following domains:

  • Policy issue flow - This includes specifying the parameters that need to be captured at the quote and application steps, your product's pricing logic, and the parameters that will be saved against the policy.
  • Policy updates and changes - This includes enabling ad hoc changes to existing policies, reactivating policies, and specifying any automated actions to be performed against policies by the platform.

Read more about how to configure your product's event hooks & actions.

Policy documents

Configured using: Workbench CLI
Changes automatically apply to existing policies: No

On Root, you can configure templates for a range of policy documents. These documents serve both as a form of communication with policyholders, and as a human readable record of important policy information.

The document templates are built in HTML, and are converted to PDF by the Root platform. Root enables the use of handlebars to dynamically reference and inject policy, policyholder and claim data into policy documents at execution time.

The creation of each document is triggered by specified events in the policy lifecycle and are typically attached to the outgoing automated communications, like email or SMS.

Read more about how to configure your product's policy documents.

Claims workflow

Configured using: Workbench CLI
Changes automatically apply to existing policies: No

Root has a multi-step claims workflow. The overall workflow is standard for all product modules on Root, but you can configure selected components within this workflow:

  • Claim information parameters - The product-specific parameters that need to be captured to allow the claim to be assessed. These parameters are configured using claims blocks.
  • Document labels - When uploading a document to the claim, the claims agent chooses from one of these labels in a dropdown menu.
  • Claims assessor checklist - A checklist displayed to the claims assessor on the dashboard, to help the assessor to verify whether all conditions for claim approval have been met.
    Disbursement requests - These components allow agents working on the claim to generate custom payout and fulfillment requests, to be processed by the insurer’s finance team. Also configured using claims blocks.

Read more about the claims workflow and how to configure claims blocks for your product module.


Configured using: Workbench CLI
Changes automatically apply to existing policies: No

Schemas allow you to configure the user interface for selected workflows on the Root management dashboard. Think of them as "forms" on the dashboard, where the schema defines which input fields to display and capture.

These workflows correspond to specific hooks that are customised for your product module. Schemas are currently supported for the quote hook, application hook and alteration hooks.

Read more about how to configure schemas for your your product's event hooks.

Note: Schemas are not required if you are using your own frontend to capture the information, or if you are sending it over the API from your own system.


Configured using: Workbench CLI
Changes automatically apply to existing policies: N/A

Root Embed is an optional feature that allows you to add a white-labelled, self-service onboarding flow to your existing digital customer journey. You can configure the look and feel of the embedded flow for each product module, making it easy to match the embed flow to your brand, and offer a seamless customer journey without writing any code.

Read more about how to configure and implement Embed for your your product module.

Communication templates

Configured using: Workbench Dashboard
Changes automatically apply to existing policies: Yes

Root allows you to configure custom email and SMS templates for customer communications, and to enable or disable a range of communication events for different policy lifecycle events.

These templates can be configured directly on the Root management dashboard (not in the Workbench CLI tool). The communications templates guide is currently a work in progress.

Data exports

Configured using: Workbench Dashboard
Changes automatically apply to existing policies: Yes

Root enables you to define data export templates per product module, allowing you to extract policy and other data as an input into your reporting process.

Data exports are configured directly on the Root management dashboard and not via the Workbench CLI tool. The data exports guide is currently a work in progress.

It is important to note that the configurable features are only a limited subset of the full suite of features offered by Root. To understand how your product will work on Root, it is also important to understand the standard platform features and how they interact with the configurable ones.

API docs

Configured using: Workbench CLI
Changes automatically apply to existing policies: N/A

Root enables you to configure API documentation for your product module. This allows you to document your product's customisable API endpoints for any external integrations, for example if you are using an external system to capture quote and application data.

Read more about configuring your product module's API docs.

Dependencies between configurable features

Product module features are interdependent, and changes to one feature can affect other features. For any change you make, you need to think through the possible side-effects and make the required updates.

The diagram below can help you to think through the knock-on effects of any product module change. It answers the question, "If I make a change to Feature X, which other features could be affected?" Note: The diagram includes only configurable features and omits standard features like policyholders and payment methods. API docs are also omitted.

The diagram divides features into four categories:

  • Workflows - These are frontend components, typically form elements, that can be configured to capture data from the user. For example, the quote schema is used to capture the rating factors that are used to calculate the premium, while claims blocks are used to capture claim information. This information is sent over the API to be processed by event hooks (except for claims blocks, which interact with the policy object directly).
  • Event hooks - These are JavaScript functions that process information received over the API. For example, the application hook processes the application input parameters and returns an Application object. (Some hooks
    like the policy issue hook, scheduled functions and lifecycle hooks do not accept new input data, and instead use existing data as their inputs).
  • Data objects - These are the objects returned or changed by the event hooks, and are stored on the Root platform. For example, the policy issue hook returns a policy object which is stored in Root's database, can be viewed on the dashboard, and can be retrieved over the API.
  • Externalisations - These are external representations of data stored on the platform. For example, the policy schedule is a document representing the policy. Data exports are representations of policy and other data in CSV format.

Dependencies between configurable product module features

To further explain how to interpret this diagram, we'll use the example of adding a new benefit to an existing product from the Add a new benefit tutorial. In this case, the insurer wants to add a new optional benefit to the product, and customers should be able to choose at the quote step whether they want to include this benefit on the policy.

In order to implement this change, we start with the quote hook, and add a new parameter that indicates whether the customer has chosen the optional benefit, and also make any required changes to the pricing logic. The API endpoint now expects this parameter, and so we also need to update the quote schema to capture and send this parameter from the frontend.

This parameter will live on the quote object, and will be passed to the application hook where it will also be added to the application object. The application object is an input to the policy issue hook, where the new parameter will be stored on the policy.

Since the policy object has changed, we will also need to update the policy schedule to display whether or not the new benefit is included on the policy. We also need to update any data export templates that use the policies data source to include the new parameter.

The policy object is also an input into the claims blocks. We need to update the claims workflow to indicate whether the customer is claiming for this benefit, and also add a new request block to enable fulfillments or payouts of this benefit. If we have any data export templates set up for the claims data source, we will need to update those templates accordingly.

What’s Next