Quote ↔ Policy conversion rules

When a quote is bound, its values become a policy. When a policy is endorsed, renewed, cancelled, or reinstated, its values pre-fill a new quote. Conversion rules are the small, explicit instructions that say which values make that trip, where they land, and how they change on the way. This page explains the idea in plain language. The technical reference for authoring rules through the API is Conversion Rules.

​

The one rule to remember

Nothing moves between a quote and a policy unless a rule says so. Two fields having the same name on the quote and on the policy does not create a connection. That sounds like extra work, and sometimes it is, but it is what makes the following possible:

• Different names on each side. Your quote can collect Insured First Name and Insured Last Name while your policy stores one Named Insured.
• Values that change in transit. Combine two fields into one, pick one of two values based on a yes/no answer, add a year to a date, or count how many times a policy has renewed.
• Values that deliberately stay put. Internal underwriter notes can live on the quote and never appear on the policy, even if both records have a field with that name.

​

What a rule looks like

A rule has four parts. You can read one like a sentence: “When binding new business, set the policy’s Named Insured to the quote’s first and last name joined with a space.” The expression always reads from source (the record the values come from) and can also read transaction.effectiveDate, the date the change takes effect. Expressions are deliberately simple and predictable: the same inputs always give the same result, so a bind done today and the same bind done next week produce the same policy.

​

Each direction is written separately

A rule that joins first and last name into one policy field does not tell the system how to split that name back apart when the policy is later renewed. So the return trip is its own rule, for example: “When renewing, set the quote’s Named Insured Override to the policy’s Named Insured.” Cancellations and reinstatements only change the policy’s lifecycle. Their Quote → Policy step carries the framework rules and nothing else; ordinary field edits belong in an endorsement.

​

What you see in the app

• Binding a quote. The new policy shows whatever the Quote → Policy rules wrote. A field with no rule is simply blank on the policy.
• Endorsing or renewing. The wizard opens pre-filled with whatever the Policy → Quote rules produced. A renewal can arrive with its end date already moved forward a year, or a description that reads “Renewal of GLP-2026-1001”.
• Viewing your rules. Administrators can browse the rules under Admin → Configuration → Conversion Rules, grouped by direction and transaction type.

​

Framework rules you keep

A handful of rules ship with every company and cannot be removed or edited: the policy type, time zone, start and end dates, and the two pricing and rating containers. They keep the policy’s identity and money consistent. Everything else in the list is yours to add, change, or leave out.

​

When you change fields

Adding a field to both the quote and the policy does not connect them. Decide what should happen and add a rule if you want the value to travel. Renaming or removing a field means updating any rule that mentions it; the configuration import tells you exactly which rule is affected and why.