Overview

This guide will help you distinguish between standard platform features on the one hand, and configurable product module features on the other. For more background on product modules, see the Product modules overview guide.

The first section, configurable features, provides examples of insurance features that you can configure as part of your product module. These features are contrasted with examples of standard platform features, which are not configurable.

The second section, dependencies between product module features, illustrates some of the interdependencies between product module features. When you change one product module feature, it's important to test that other features that depend on it still work as expected.

Configurable features

This section provides an overview of the features that can be configured for each individual product module, and contrasts them with standard platform features. Some features are optional, and this section does not provide an exhaustive list of all available features.

Configured using Workbench CLI

You can configure these features using the Workbench CLI. Note: Updating any of these features creates a new product module definition. This means that updates are not automatically applied to existing policies.

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 fulfilment requests	- Three-step claim workflow - Capturing claimant information - Capturing beneficiary details - Claim assessment workflow (except assessor checklist) - Assessment confirmation workflow
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.
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 on Workbench Dashboard

You can configure these features using Workbench dashboard. Note: These features are not associated with a specific product module definition. This means that updates automatically apply to all policies, including existing policies.

Domain	Configurable features (examples)	Standard features (examples)
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
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

Dependencies between product module features

Product module features are interdependent, and changes to one feature can affect other features. For any change, it's important to understand and test all possible side-effects.

The diagram below 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 and Embed are also omitted.

The diagram divides features into four categories:

Workflows - Frontend components, typically form elements, that can be configured to capture data from the user. 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 - JavaScript functions that process information received over the API. Some hooks
like the policy issue hook, scheduled functions and lifecycle hooks, do not accept new input data, but 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.
Externalisations - These are external representations of data stored on the platform.

1037 — 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. This parameter will be present on the returned quote package object.
The quote package is passed to the application hook where the new parameter will also be added to the application object.
The application object is an input to the policy issue hook, and the new parameter will be stored on the policy object.
Since the policy object has changed, we need to update the policy schedule to show the new benefit, as well as any customer notifications templates that reference policy benefits. We may also need to update scheduled functions, lifecycle hooks and alteration hooks, which accept the policy object as a parameter. Finally, we may need to update any data export templates that reference policy benefits.
The policy object is an input into the claims blocks, which we need to update to indicate whether the customer is claiming for the new benefit. If we have any data exports relying on the claims data source, we may need to update those templates in turn.