Skip to main content
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. Most values make that trip unchanged. Conversion rules are the small, explicit instructions for the exceptions: a value that should stay behind, or one that should land somewhere else or 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

A field on both the quote and the policy, with the same name and type, is copied unchanged unless a rule says otherwise. A rule is only needed for an exception:
  • Leave a value behind. A rule of SKIP() stops one field from being copied. Internal underwriter notes can stay on the quote and never reach the policy, even when both records have a field with that name.
  • Different names on each side. Your quote can collect Insured First Name and Insured Last Name while your policy stores one Named Insured. A rule writes the policy field from the quote fields.
  • 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.
A field that exists on only one record is never copied. It crosses only when a rule writes it.

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. SKIP() and CLEAR() are different. SKIP() writes nothing, so the field is not copied. CLEAR() writes an empty value.

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 switch the policy off and on. Their bind copies nothing and runs no rules, and their Quote → Policy rule sets hold only the framework rules. Ordinary field edits belong in an endorsement.

What you see in the app

  • Binding a quote. The new policy has every shared field’s value from the quote, plus whatever the Quote → Policy rules wrote. A field that a rule skips, or that exists only on the policy, is blank on the policy unless your configuration calculates it.
  • Endorsing or renewing. The wizard opens pre-filled with the policy’s shared fields and whatever the Policy → Quote rules produced. A renewal can arrive with its start date moved to the new term, or a description that reads “Renewal of GLP-2026-1001”.
  • Viewing and authoring your rules. Administrators find the rules under Admin → Configuration → Conversion Rules, grouped by direction and transaction type. The page lists only the rules. Shared fields that are copied without a rule do not appear there. Select Edit to add, change, or delete a rule, then Ship to make your changes live.

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, the premium and rating containers, and the billing copy, which copies a new-business, endorsement, or renewal quote’s billing to the policy unchanged. They keep the policy’s identity and money consistent. The Conversion Rules page marks each one Framework-pinned and offers no Edit or Delete for it. Everything else in the list is yours to add, change, or remove.

Set the renewal end date

No framework rule sets a renewal’s end date, because each company decides it. Without a rule, a renewal pre-fills with the expiring term’s end date. Add a Policy → Quote rule for renewals that writes policyEndDate: SKIP() to leave it out of the pre-fill, or an expression that works out the new end date.

Fields your rating reads

When you rate an endorsement, the whole term is rated again. The part the endorsement changes is rated from your quote. Every other part is rated from your quote with each shared field’s value copied from the policy for that part of the term. Policy → Quote rules play no part in rating. So a field your rating reads must exist on both the quote and the policy, with the same name and type, and binding must copy it unchanged: no SKIP() and no expression that changes it in the Quote → Policy rules for new business, endorsement, or renewal. Otherwise the parts of the term the endorsement does not change are rated on the wrong value, and nothing warns you.

When you change fields

Adding a field to both the quote and the policy, with the same name and type, makes it travel in both directions straight away. Add a SKIP() rule for each transaction where it should not. Renaming or removing a field means updating any rule that mentions it; the configuration import tells you exactly which rule is affected and why.
Deleting a rule for a shared field means the field is copied again. That includes deleting a SKIP() rule. To stop a field from crossing, keep or add a SKIP() rule; don’t delete it.