Part 3: Issuing policies
Learn how to bind a quote and a policyholder to create an application.
Useful documentation
- Application hook
- Application object
- Create an application API reference
- Policyholder object
- Create a policyholder API reference
- Policy issue hook
- Policy object
- Issue a policy API reference
- Coding standards
- Schemas
- Testing product modules
Overview and success criteria
✅ An application can be created via API, or the Root Dashboard.
✅ Application data validation passes according to the specifications.
✅ Unit tests are written for the application creation.
✅ Schemas have been created to get an application on the Root Dashboard.
✅ A policy can be issued via API, or the Root Dashboard.
✅ The data collected in the quote and application is stored on the policy module data.
Watch our explainer videos:
Watch the video Policy Lifecycle: Issue a Policy to learn more about how to configure the policy issuing flow on the Root platform:
In this section, we want to be able to bind a quote and a policyholder to create an application. This should be possible via the Root API or Dashboard. Subsequently, a policy needs to be issued using the aforementioned application.
To successfully achieve this, follow these four steps:
- Start by creating an application validation schema with Joi that abides by the specifications below.
- Return an application with the correct pricing logic specified below. Remember to create an application, a policyholder needs to be created.
- Write the corresponding schema in the application-schema.json file.
- Create unit tests that thoroughly test validation, pricing and that the expected application is being created.
- Define the policy issue hook to issue a policy.
Application validation, pricing and creation
When we receive specifications from clients, the team will capture business rules, input parameters and the pricing logic for the application creation to be built. We will follow the same pattern in this section.
Business rules
| Ref | Details |
|---|---|
| A1 | The name of the dinosaur needs to be provided and must be less than 100 characters. |
| A2 | The colour of the dinosaur needs to be provided and must be one of the following [Lilac, Sea green, Granite grey, Midnight blue] |
| A3 | The dinosaur’s National Dinosaur Registry Number (NDRN) must be provided and should be a number between 100,000 and 999,999. |
Input parameters
This information is not relevant for calculating the premium but will need to be provided for identification and verification purposes if any claims are made against the policy. The quote_package_id and policyholder_id need not be validated in the validation schema, because they will be validated on the platform.
| Field Name | Type | Requirement | Restrictions |
|---|---|---|---|
| quote_package_id | string | Required | Must be the returned quote_package_id from the /quote response. |
| policyholder_id | string | Required | Must be a valid policyholder_id on the Root Platform. |
| dinosaur_name | string | Required | Defined in the business rules. |
| dinosaur_colour | enum | Required | Defined in the business rules. |
| ndrn | string | Required | Defined in the business rules. |
Issue a policy
To issue a policy, the policy issue hook needs to be defined in the Product Module, but no further data is collected at this point. The following parameters need to be returned when the policy is issued
| Parameter | Value | Description |
|---|---|---|
| policy_number | Use generatePolicyNumber() function | The UUID of the policy. |
| package_name | DinoSure | The insurance package name. Searchable field on the dashboard. |
| sum_assured | Obtained from the application object | The amount, in cents, of the total value insured. |
| monthly_premium | Obtained from the application object | The amount, in cents, of the total monthly premium. |
| base_premium | Obtained from the application object | The amount, in cents, of the total monthly premium. |
| start_date | Obtained from quote data | The date that cover starts. |
| end_date | Must equal null | The policy expiration date. |
| module | Obtained from the quote and application module data | All of the data was collected to get a quote and create an application. |
Testing
The scenarios below should have unit tests written for them to show that the logic has been implemented correctly:
- A payload with valid data passes validateApplicationRequest.
- A payload with invalid data fails validateApplicationRequest.
- A created application has all of the data from the quote and application step.
- A created policy has all of the data from the quote and application step.
If you're doing the Root certification:
Once you’ve worked through the changes above, submit it as a pull request into the
mainbranch on your Github repository. In the PR description, copy and answer the questions below in the last section Part Specific Questions. Message your facilitator to review the PR when ready.Questions:
- Why do you think some information is only captured at the application step and not the quote step?
- Was it easier to do the application and policy step following the implementation of the quote step? Meaning, were there a lot of similarities you could leverage to get on easier with the task.
You can proceed to the next part without being blocked by the facilitator, but be sure to branch off of this part’s branch to ensure that these workings are in place for the next part. You will be required to ship a new PR for the next Part.
Updated 4 months ago