Product module updates and deployments
Understand the processes and practices used to coordinate on product module updates and deployments
Overview
This guide describes processes and practices we use to coordinate with you on product module updates and deployments. We strongly recommend that you familiarise yourself with the Product modules overview and Product modules features guides before starting any product module development work.
The below, taken from the Product modules overview guide, is included here for ease of reference.
Workbench development support
To kick off your product module development on Workbench, the Root team will provide you with the following.
- Access to the Root platform.
- Access to the getting started guide and the Dinosure tutorial.
Root access
If you don't yet have access to Root and you're interested to play around or build a new insurance product, get in touch with us. If you're already on Root but stuck, reach out to us on our Community Forum and we'll get you back on the road soon.
Two phases: pre-launch and post-launch
There are essentially two major phases of the product module lifecycle: Pre-launch (not selling production policies) and post-launch (selling production policies). Regardless of phase, you should always do testing in the sandbox environment.
Pre-launch
During the pre-launch phase, only sandbox policies can be issued (using either the live or draft product module definition). This means you can use the live and draft version of the product module to separate functional pieces of the build from work in progress.
As an example, after the policy issue flow has been built, it can be deployed for stakeholders to test (in sandbox) using the live product module definition. Developers can continue to work on the draft version in parallel to build new features for the product, deploying to live each time a new piece of functionality is ready. The live version of the product module represents the latest bug-free, functional version. On GitHub, the main branch should always match the latest deployed (live) version. More on this in the Git workflow guide.
The advantage of separating draft and live in the pre-launch phase is that you can control what can be demo'd to and tested by stakeholders. In parallel, you can continue to rapidly build and test features using the draft product module definition.
Post-launch
Once the product is ready to launch it will enter the post-launch phase. This is the moment when the first live policy is sold on the product. From this point forward, it is crucially important that features deployed to the live definition are 100% functional, because the live definition used to issue real production policies to real policyholders.
After launching the product, new features may be added to the product. Stakeholders will now have to test new features using the draft version in order to not affect production policies. Feature development and stakeholder testing can no longer be performed in parallel on the same product module.
Deployments
Before any product module changes are deployed to live, all testing should have be complete. As part of the deployment, a Root team member will publish the product to a new major version. If the deployment is an update to a live product, the Root team will also trigger an internal workflow to ensure that all production policies are associated with the latest live product module definition.
Build considerations
Whether deploying a product module for the first time or evolving an existing one, the following are important aspects that need to be considered:
| Build aspect | Considerations |
|---|---|
| Policy issuing flow | configured pricing logic, rating factors and validations |
| Administering existing policies | configured reactivations and alterations. |
| Automated actions for existing policies | configured lifecycle rules and anniversary logic. |
| Claims | configured and disbursement blocks working as expected. |
| Policy documents | terms file PDF uploaded and HTML document layout and merge variables rendering as expected. |
| Customer notifications | configured with email layouts and merge variables rendering as expected. Communications journey reviewed to ensure no duplicate notifications are triggered. |
| Billing | configured with expected behaviours tested including pro-rata and billing detail updates. |
| Data exports | configured and handlebars returning expected field values and filters appropriate records. |
| API docs | updated and reflect the API interactions for the product design. |
Communication configuration
To avoid sending unnecessary notifications to your customers, make sure to review the email and SMS events enabled. For example;
• 'Policy Updated' and 'Alteration Package Applied' both fire when an alteration package change is saved on a policy.
• The payment method activated events such as 'External Payments Activated' fire when a payment method is saved on the policy and include the welcome letter if enabled. If utilising the welcome letter document, these are the recommended events to enable rather than 'Policy Issued'.
Deployment readiness
We encourage our clients to follow our product module build standards guide to ensure products are robust and launch-ready.
For the first deployment of your product, here are some things to check:
✅ Endpoints being invoked are pointing to the live API e.g. api.rootplatform
✅ A production API key has been created.
✅ You have subscribed to the Root Status page
✅ All required users have been added to the Root Dashboard with appropriate permissions.
Testing
Clients are responsible for end-to-end testing of their product module code. Should you require assistance or advice in building product modules using Workbench, our professional services team is available to assist.
Updated 21 days ago