A payload field called collision deductible has no single home in Guidewire PolicyCenter. It sits on a coverage term, under a coverage, under a vehicle, under a line.
Vendors, MGAs and TPAs that send data to Guidewire carriers run into this on the first payload. A field that matches one-to-one in the source system still needs a specific layer in Guidewire, and the wrong layer puts the data in the wrong place.
This article explains the line, risk and coverage layers, shows where mappings break, and gives a five-step order for mapping each field.
What Are the Line, Risk and Coverage Layers in Guidewire?
Guidewire organizes a policy into a line, the things covered under it, and the coverages attached to each. Guidewire calls a covered thing a coverable, the layer this article calls risk.
Guidewire's Cloud API Consumer Guide defines each layer, and the table below pairs each one with its Personal Auto example.
Layer | Guidewire term | Personal Auto example |
|---|---|---|
Line | Line | Personal Auto Line |
Risk | Coverable | Vehicle |
Coverage | Coverage | Collision coverage for a specific vehicle |
Detail | Coverage term | Deductible on that collision coverage |
Source systems name the covered thing in their own words, such as risk, item or insured object. Guidewire's documentation uses coverable, so a mapping sheet needs a column that translates each source term.
Line and Coverable: The Upper Layers
A line is the set of information that defines a type of product an insurer offers, such as Personal Auto. A coverable is a thing the policy covers, such as a vehicle.
Both layers vary by line of business. Developers reach them through line-specific endpoints, and the developer must generate those endpoints.
Coverage and Coverage Term: The Lower Layers
A coverage is a specific type of covered loss for a coverable, such as collision for one vehicle. A coverage term is a value that limits that coverage, such as its deductible.
Why Does One Source Field Map to Different Layers?
The same kind of source data lands on different layers depending on what it protects. Guidewire splits coverages into line-level and coverable-level, and a mapping that ignores the split attaches data to the wrong object.
Line-Level Coverages Apply to the Whole Policy
Liability for bodily injury and property damage in Personal Auto attaches to the line. It applies to everyone the policy covers, so it attaches once, to the line, instead of to each vehicle.
Coverable-Level Coverages Attach to One Item
Collision attaches to a specific vehicle. A payload with three vehicles needs collision mapped to each vehicle separately, and each one carries its own deductible.
Hierarchies Add Another Level
Some lines nest one coverable inside another. In Guidewire's example, a Commercial Property line holds buildings, and each building holds equipment, with coverage endpoints at every level.
A flat list of property coverages in the source file has to be split by level before it maps.
What Else Sits Beside Coverages in the Policy?
A Guidewire policy holds more than coverages. Modifiers, questions, exposures, exclusions and conditions each have their own structure, and none of them are coverages.
Rating and Underwriting Content
A modifier carries rating information that is not tied to one coverage, such as an anti-lock brakes discount. A question pre-qualifies an account or gathers rating information.
An exposure such as a driver informs pricing, yet no coverage attaches to the driver.
Content That Is the Same in Every Line
Policy contacts and policy locations keep one structure across every line. Lines, coverables, coverages and coverage terms do not. A mapping built for Personal Auto needs a fresh pass for Commercial Property.
Where Do Field Mappings Break in PolicyCenter?
Mappings break where a field lands on a layer that PolicyCenter rejects. Guidewire's default coverage validation blocks specific behaviors, and each one traces back to a layer mistake.
Coverage Errors
In most cases, PolicyCenter does not let a caller create an unavailable coverage or delete a required one. A payload that sends a coverage that is unavailable at the time of the call, or removes a required one, fails here.
Coverage Term Errors
Coverage terms carry more checks. PolicyCenter refuses values for unavailable, read-only or hidden terms, values outside the allowed minimum and maximum, and options or packages that are unavailable.
A deductible sent as a value the product does not offer fails here.
One Error Can Stop the Rest
By default, Cloud API validates with every call, and a validation error in one call can prevent later calls from executing. A single misplaced coverage can hold up the rest of a submission.
Deferred validation waits until the caller puts the submission into a state it considers consistent. Guidewire offers it to non-interactive callers with sufficient authorization.
How Do You Map Fields Layer by Layer?
Map from the top down, from line to coverable to coverage to coverage term. Each step narrows where a field can land.
The Five Steps
Name the line. Confirm the payload's line of business matches a Guidewire line before mapping any field.
List the coverables. Pull each vehicle or building into its own object.
Sort coverages by level. Mark each coverage as line-level or coverable-level, then attach coverable-level coverages to the correct item.
Attach coverage terms. Place each deductible or other term on the coverage it limits.
Check Guidewire's defaults. For installed products, PolicyCenter creates available coverages marked Required or Suggested when a line or coverable is created, and it adds required coverage terms when each coverage is created. Compare your payload to those defaults before you map.
Example: A Three-Vehicle Personal Auto Payload
Step 1 names the Personal Auto line. Step 2 creates three vehicles. Step 3 maps liability once to the line and collision once to each vehicle.
Step 4 places a deductible on each collision coverage. Step 5 checks which of those coverages and terms Guidewire already created.
Run the five steps once per line, because the structures differ by line.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving submission data into Guidewire. LiLa, our insurance-trained LLM, drafts the field mapping from your payload to the PolicyCenter structure, including package products that map one source to many coverages. A person on your team reviews and confirms every mapping before data moves.
The InsOps Integration Gateway gives MGAs, brokers and underwriting vendors a prebuilt route into Guidewire PolicyCenter. Senders register in a self-service portal, bring their payload, and configure it without building their own connector. The gateway runs inside your own environment, so PII and PHI stay in controlled infrastructure. InsOps is a Guidewire technology partner.
For the wider case behind this model, read why standardized API gateways are replacing point-to-point connections. If you are evaluating how to exchange submission data with Guidewire without a custom connector build, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is field mapping in Guidewire?
Payload mapping matches each field in a sender's data to the field Guidewire expects, so a submission or claim lands in the right place on the first send. Each field resolves to a line, coverable, coverage or coverage term.
Why is Guidewire field mapping harder than matching field names?
A source field needs a layer, not only a name. Guidewire separates line-level and coverable-level coverages, nests some coverables inside others, and keeps each coverage term on its own coverage.
What does coverable mean in Guidewire?
In Guidewire's documentation, a coverable is a thing covered by the policy, such as a vehicle or a building. Coverages attach to it.
Does a mapping built for one line work for another line?
Not without review. Line, coverable, coverage and coverage term structures vary by line of business, so each line needs its own pass.
How does the InsOps Integration Gateway help?
It gives senders a prebuilt route into Guidewire, where LiLa drafts the payload mapping. A person confirms every mapping before data moves.
What happens when a coverage lands on the wrong layer?
Default coverage validation in PolicyCenter blocks unavailable coverages and out-of-range coverage terms. One validation error can also stop later calls, so a wrong layer shows up as a failed submission.
How do you check a mapping before data moves?
Walk a sample payload through the five steps and confirm every field has a layer. Then have a person who knows the carrier's product confirm the result.