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.

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.

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:

You issue Policy A.
You change the logo on the policy schedule template.
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. The bumping process is managed internally and is usually done after COB on the same day of deployment.

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).

Domain	Configurable 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
Claims 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
Customer notifications Email and SMS customer notifications sent to policyholders	- Email templates - SMS templates - Enabling / disabling individual customer notification events	- List of supported customer notification events - The attachments included with each customer notification event
Billing 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

Settings

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 customer notifications, 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 fulfilment 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.

Schemas

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 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.

Embed

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 and policy management solution 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 product module.

Customer notifications 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 customer notification events for different policy lifecycle events.

These templates can be configured directly on the Root management dashboard (not in the Workbench CLI tool). The customer notifications 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.

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.

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

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.