The Option Sync Trap

A clause that used to appear in every generated contract quietly stops appearing. Nobody changed the rule. Nobody changed the clause text. Someone only renamed an option in a dropdown, and now the conditional clause keyed to that option never fires.

This is the option sync trap, and it is the most common way a working template silently breaks. It happens because a single option label is stored independently in four different places, and Pactly does not keep them in sync for you. Editing one copy leaves the other three pointing at the old value. This article explains where the four copies live, why they drift, and what to check whenever you touch an option.

When a deal term is a choice (an NDA variant, a jurisdiction, a service tier, a yes/no gate), the label of that choice gets written down separately in each system that has to reason about it. None of them references a shared definition. There is no single source of truth.

Take one option, say a contract variant called Pre-Employment. That exact string ends up living in:

1. The contract property: the option list on the property. This is the canonical-looking list, but it is not authoritative over the others.
2. The form field: each form’s own copy of the choices a submitter can pick. A field bound to the property still carries its own option list, per form. Two forms feeding the same template each hold their own copy.
3. The value map: the template’s lookup table that turns the selection into document text, where each choice has a Choice label and a Replace value. The label here must match what arrives from the form.
4. The rule condition: the named rule that decides whether a conditional clause is included. The rule compares the incoming value against the option label stored in its condition.

The value flows form field → property → template at generation time. The value map renders the chosen text, and the rule fires its clause, only when the label they compare against is byte-for-byte the same as the value that arrived. Change the label in one place and the comparison fails everywhere downstream.

Each store is edited on its own screen, by its own action, with no cross-update. Renaming the option on the property updates only the property’s option list. Renaming the choice on a form field updates only that one form, and now that form sends a value nothing recognizes. Renaming the Choice label in the value map, or the option in the rule’s condition, updates only the template config, not the property or the forms still sending the old label.

So the moment a submitter picks the renamed option, the form sends (say) Pre-Employment NDA, the value map still keys on Pre-Employment, no choice matches, and the rule comparing against Pre-Employment evaluates false. The clause does not appear. Nothing errors. The contract generates, looks plausible, and is simply missing a clause, or shows a value-map gap rendered as the [●] placeholder where the mapped text should have been.

Treat an option label as a shared key that you are responsible for propagating by hand. Whenever you add, rename, remove, or reorder an option, update all four copies in the same change, and re-test generation before you consider it done. The comparison is a literal, exact string match: Pre-Employment and Pre-Employment (trailing space), or a changed capitalization, are different values and will not match.

1. Update the option on the contract property, in the Word add-in template editor.
2. Update the choice on every form field bound to that property, on every form that feeds the template, in the web-app Forms section. A renamed option is not auto-pushed to existing form fields; open and re-save each field.
3. Update the Choice label in the template’s value map so it matches the new string exactly. The Replace value is the document text and can stay.
4. Update the option in every rule whose condition tests that value.
5. Generate a contract from each affected form and confirm the value map renders and the conditional clause appears or hides as intended.

Work the chain backwards from the missing clause:

1. Read the generated document. A missing clause points at a rule mismatch; a [●] where text should be points at a value-map (or variable) miss.
2. Check the value the form sent. Compare the submitted option string against the rule’s stored option and the value map’s Choice label, character for character, including case and trailing spaces.
3. Find the copy that drifted. Usually one store was edited (a form field renamed, or the property changed) and the template config was left behind, or vice versa. The value map and the rule are separate config, so a clause can render its value-map text but still fail its rule (or the reverse) when the label was fixed in one and not the other. Check both.
4. Re-align all four, then regenerate to confirm. Template edits affect new contracts only; existing contracts must be regenerated to pick up the fix.

• Templates Overview
• Conditional Logic and Rules
• Mappings: Forms and Properties
• Form Field Mappings & Naming
• Form Conditional Logic
• The Pactly Word Plugin