Here are some examples:
It’s important to be aware of the following relationships and behaviors, which are documented in more detail below.
Whether you are building a static application or using Herald’s Dynamic Application, you’ll need to work with risk and coverage parameters. Every individual risk or coverage parameter has information associated with it, like the products it’s relevant for, any associated conditionality, the text for the question, the acceptable values….the list goes on.
If you are building a static application, you’ll have to get this information from the Appendix. The appendix serves as our question library, listing each question and all of its associated data. If you use the Dynamic Application, all of this information is provided in the [.h-endpoint-link]/applications[.h-endpoint-link] response.
While the information is the same, we’ll take a look at how this data is provided when using the Dynamic Application. Each risk and coverage parameter returned in the application response includes the following metadata:
Some risk parameters are only required under certain conditions. For every risk parameter, the Appendix specifies if it is conditional, and if so, lists its specific conditions. If a risk parameter does not have any conditions listed, then it is required whenever requesting any of that parameter’s relevant products.
If you’re using the Dynamic Application, every parameter that can potentially yield conditional questions is assigned the property [.h-code]affects_conditions: true[.h-code]. Conditional questions will only be returned if they become relevant after you submit a value. Let’s look at a case where you receive a [.h-code]risk_parameter[.h-code] for the applicants Home State. You would submit that value by sending in:
If the product you are using has conditional logic to ask every applicant in the state MA for their legal entity type, the following response would look like this:
Risk parameters describe the risks associated with the applicant. For example, the parameter “loss free years” describes the number of previous years that the applicant has gone consecutively without a loss. Here’s how we would reflect that an applicant has 3 loss free years:
By default, risk and coverage values are associated with the entire applicant. However, certain risks and coverages only relate to a subset of the applicant. These subsets are defined by “parent parameters”, and their associated “child parameters” denote that are only related to the level of their parent. A parent parameter has a [.h-code]risk_parameter_id[.h-code] (or [.h-code]coverage_parameter_id[.h-code]) and [.h-code]value[.h-code] as usual, with the addition of a [.h-code]child_risk_values[.h-code] (or [.h-code]child_coverage_values[.h-code]) that contains an array of child parameters and their values.
If you’re using the Dynamic Application, these child parameters will come back in the response as they become relevant. These relationships are also documented in the Appendix.
For example, let’s say that this same applicant has several locations providing several services. Specifically, their Hill Valley location is associated with the class code [.h-code]96816[.h-code] (Janitorial Services). Since “Janitorial Services” describes the nature of the risk only at this location, we would show that information like this:
Some risk and coverage parameters can have multiple values. Parameters with this concept are given the property [.h-code]creates_array: true[.h-code], and each instance of that parameter is given a unique [.h-code]instance[.h-code] to distinguish between them.
The example we referenced earlier was an applicant that has multiple locations. In this case, the parameter [.h-code]rsk_yor8_location[.h-code], which is for Location, should appear twice. Today, we automatically generate and return the next incremental instance in the Dynamic Application for all [.h-code]creates_array: true[.h-code] parameters. A few things to note for these situations:
In this example, those parameters would look like this:
When formatting parameters that can have multiple values on a front-end application, it’s important to give an applicant the option to create new instances. Some applicants may have 1 location, and others may have 20. Read our guide on building a front-end application to learn more. You can also read our guide to using instances to map values to their correct instance.