Managing Properties: Best Practices and Pitfalls

Most property problems are silent. A report column comes out blank, a field turns up on contracts it shouldn’t, a filter quietly skips records that should match. Nothing throws an error, so the issue can sit unnoticed until someone spots that the numbers are off.

Almost every one traces back to one idea: a property has two parts, and editing one does not rewrite the other.

Editing a definition does not rewrite the values already on existing contracts. Properties are also wired into templates, forms, workflow rules, filters, and exports, so a small edit can ripple outward. This page walks the edits that break things silently, and the safe way to make each one.

Every property has a label (the display name) and a key (the underlying identifier). The key is what templates, forms, workflow rules, filters, and exports point at. Renaming the label does not change the key, so everything keeps working.

The trap is the reverse. If a report, template, or rule points at a key that does not exist (a typo, a key from another property, a changed key), it fails silently. The export column comes out blank, the template token resolves to nothing, the rule never matches.

Keys are deliberately hard to change. A key is set when the property is created and only master admins can edit it, in the property editor’s Admin settings under Settings → Manage Properties. Everyone else sees the key as read-only. Treat it as permanent once anything references it.

The trap: a definition change does not land on every contract the moment you save.

Symptoms right after an edit:

• Existing contracts still show the old definition until a background job catches up. There is no progress indicator, so the lag is invisible.
• Values already entered are never rewritten. The job syncs the definition attached to each contract, not the data captured before.

Safe action: allow a few minutes, then revisit a few affected contracts and forms to confirm, rather than assuming the edit applied everywhere at once.

On List and Multiple options properties, renaming an option is safe. When you rename “Govt” to “Government”, Pactly migrates the existing contract values for you: every contract that stored “Govt” is rewritten to “Government” in the same save (the toast confirms it migrated existing data), and the matching choices in templates and form fields update too. Reporting and filtering see a single value, with no manual cleanup.

Deleting an option is the unsafe move. Deleting does not migrate stored values, so contracts that already held the deleted option keep an orphaned value that no longer exists in the list. A filter for the live options silently misses those records, and there’s no warning.

So: rename when a label is wrong, and rename or deprecate instead of deleting when an option is no longer offered. If you must remove an option, rename existing contracts onto a surviving option first.

The trap: filters and rules compare the stored value character for character, so invisible differences break the match. "Government " (trailing space) never matches "Government", and those records quietly drop out.

Safe rules when building List and Multiple options properties:

• Trim leading and trailing spaces from every option.
• Keep capitalization and spelling consistent ("Non-Profit" and "Non profit" are different values).
• Consolidate near-duplicates that mean the same thing into one option.

The trap: deleting a property is destructive and not reversible. It clears the property’s reference off every contract that held a value, every form field mapped to it, every playbook that used it, and every workflow rule that tested it. Historical contracts lose the data point, and any past reporting that relied on it breaks.

Almost always the goal is “stop using this going forward,” not “erase its history.” Deprecate instead:

1. Relabel it to signal retirement, for example prefix the label with [Deprecated].
2. Mark it Manual only so it stops being added to new contracts automatically. (This is the only flag that actually halts auto-attach; narrowing the property’s Contract type tag does not.)
3. Drop its sort order so it sinks to the bottom of the list.

The property and its history stay intact, but it no longer clutters new contracts. Reserve deletion for properties created by mistake that never held meaningful data.

The trap: people assume the Contract type tag on a property controls where it appears. It doesn’t. That tag only filters the admin Manage Properties list. What actually puts a property on a contract is how it attaches:

• Globally default: a property marked globally default (master-admin only) auto-attaches to every new contract, regardless of category. If a field is turning up on contract types it doesn’t belong on, this is almost always why.
• Manual only: the lever to keep a property off new contracts. Mark a property Manual only and it’s added by hand only where it’s needed, instead of attaching everywhere.

Safe action: if a property appears where it shouldn’t, check whether it’s globally default and switch it to Manual only. To trim a contract type’s compact sidebar without changing what’s attached, use the per-type Show in miniview flag on the Settings tab. Neither is controlled by the property’s Contract type tag.

The trap: contract properties and party attributes look identical (both typed custom fields with labels, keys, and option lists), so it’s easy to configure one when you meant the other. They live in separate systems.

If the value is about the agreement (its value, dates, risk tier), it’s a contract property. If it’s about who you’re contracting with (their industry, region, entity type), it’s a party attribute. They share the same model and every gotcha above, but configuring one does not configure the other. When a property “won’t fill in,” confirm you’re describing the contract, not the party.

• Properties & Categories
• Contract Types (Categories)
• Creating Contract Properties
• How Property Values Get Captured and Used
• Routing Approvals by Category, Value, and Properties