Form Patterns Overview
Form patterns are not new to PolicyCenter, so you might already be familiar with them. However, the ability to access them from Cloud API is new, as of the Innsbruck release. So if you already know all about form patterns in the user interface (UI) and only want the technical overview, feel free to skip ahead to the next section.
For those of you who are still here, I’ll explain what form patterns are. When someone takes out an insurance policy, there is a lot of paperwork involved. Sometimes it’s electronic, sometimes it’s actual paper, but either way, there’s usually a lot of it. That paperwork consists of the forms detailing the terms of the policy and all the legal stuff that goes with it. Guidewire does not store those forms. All of those forms are in a document management system somewhere that is not Guidewire.
We do, however, have to be able to identify those forms. That’s where form patterns come in. A form pattern provides the information that is required to identify which forms go with each policy.
Forms are assigned to policies automatically when a job is created; you can’t explicitly associate a form with a policy. Where and when the form is associated depends on the information supplied in the form pattern. For example, a form can be associated with a policy when a job is bound or quoted, and can be restricted to one or more specified job types such as submission or renewal.
Form patterns can also include information about jurisdictions (such as a specific state or region) and policy start and end dates.
Policies matching the criteria specified in a form pattern will automatically be assigned the form the pattern represents.
Form Patterns Endpoint
It actually takes quite a bit of information to identify policy forms and determine which policies they should be applied to. In the UI, there are six tabs’ worth of information to do this.
With Cloud API, all this information can be accessed through two endpoints: form-patterns and lookups.
form-patterns endpoints
- GET /admin/v1/form-patterns
- GET /admin/v1/form-patterns/{policyFormPatternId}
- POST /admin/v1/form-patterns
- PATCH /admin/v1/form-patterns/{policyFormPatternId}
- DELETE /admin/v1/form-patterns/{policyFormPatternId}
lookups endpoints
- GET /admin/v1/form-patterns/{policyFormPatternId}/lookups
- GET /admin/v1/form-patterns/{policyFormPatternId}/lookups/{lookupId}
- POST /admin/v1/policy-form-patterns/{policyFormPatternId}/lookups
- PATCH /admin/v1/form-patterns/{policyFormPatternId}/lookups/{lookupId}
- DELETE /admin/v1/form-patterns/{policyFormPatternId}/lookups/{lookupId}
The form-patterns endpoints provide access to all of the information relating to form patterns except jurisdiction availability. The lookups endpoints provide access to all information related to the jurisdiction availability. Here are some examples.
This is a sample response from a GET operation on the form-patterns endpoint:
{
...
"attributes": {
"code": "FormIL17",
"edition": "00 00",
"endorsementNumbered": true,
"formNumber": "PF 01",
"genericFormInference": {
"code": "GenericAlwaysAddedForm",
"displayName": "No additional criteria"
},
"id": "pc:100",
"inferenceTime": {
"code": "quote",
"name": "Quote Time"
},
"jobTypes": [
{
"code": "Renewal",
"name": "Renewal"
},
{
"code": "Submission",
"name": "Submission"
}
],
"name": "Common Policy Conditions",
"priority": 2,
"products": [
{
"displayName": "Personal Auto",
"id": "PersonalAuto"
}
],
"reissueOnChange": false,
"removalEndorsement": false
},
...
}
- The Form Code is FormIL17.
- The Form Number is PF 01.
- The Name of the form is Common Policy Conditions.
- The form applies only to the Personal Auto product.
- The form will be applied to appropriate policies when they are quoted.
- The form will be applied to a policy on job submission or renewal.
In addition to general form information and under what circumstances to apply the form to a policy, a form pattern also needs to specify which policies to apply the form to based on certain availability information. This is found with the lookups endpoint. Here is a sample response from a GET operation on the lookups endpoint:
{
...
"attributes": {
"availability": {
"code": "Available",
"name": "Available"
},
"id": "pc:150",
"jurisdiction": {
"code": "CA",
"name": "California"
},
"startEffectiveDate": "2024-01-19T08:00:00.000Z",
"uwCompanyCode": {
"code": "3111_33333",
"name": "Acme High Hazard Insurance"
}
},
...
}
In this example, the form is currently Available to be applied to policies, but only to policies that are in the state of California, become effective starting January 19, 2024, and are underwritten by the Acme High Hazard Insurance company. The only required fields are availability and startEffectiveDate, which means you can leave jurisdiction blank (null). In that case the form will be automatically applied to all policies as of the startEffectiveDate.
You can also retrieve a list of forms that have been applied to a job or policy, using these endpoints:
- GET /job/v1/jobs/{jobId}/forms
- GET /policy/v1/policies/{policyId}/forms
As I mentioned earlier, you can’t explicitly assign a form to a policy, but once the form has been automatically assigned you can use these endpoints to view the form information.
Learn More
To get more details and see complete examples using the form patterns endpoints, refer to the PolicyCenter Cloud API documentation.
About the Author
Jean Stemp
Senior Technical Writer