A customer signs an agreement based on certain numbers: a contract value, a balance, a list of items, a fee rate. Six months later, those numbers have changed. Items were added or removed, balances moved, and the deal looks different in the CRM than it did on signing day. Now someone asks a simple question: which number should the fee, the commission or the report use?
If your CRM only stores the live value, you can't answer it reliably. This guide explains the difference between snapshot values and live values, when to freeze data at signing, and how to set it up in Salesforce and HubSpot.
Snapshot vs. live values in CRM is the choice between storing a number as it was at a key moment, such as contract signing, and storing it as it is now. Most businesses need both. Capture an "at signing" copy of amounts, rates and counts that drive fees, commissions or commitments, and lock it. Keep live fields for day-to-day service and forecasting. Decide in writing which value each calculation and report uses. Vantage Point designs these data models through its Salesforce and HubSpot implementation services.
A live value reflects the current state of your data. A roll-up of related items, a formula based on today's balance, or a field synced from another system all update automatically. That's exactly what you want for service work and forecasting.
A snapshot value is a copy taken at a specific moment and then left alone. "Contract value at signing," "committed amount at signing" and "rate at close" are all snapshots. They answer the question, "What did we and the customer agree to?"
The trouble starts when a single field tries to do both jobs. If "Total Amount" is a live roll-up, it's no longer the signed amount the first time anything changes. Reports built on it quietly rewrite history.
Freeze a value whenever something important is calculated from it or promised against it. Common examples:
If nobody calculates anything from a value and nobody will ever ask what it was on a past date, a live field is fine.
This is a business decision, not a technical one, and it should be written down. A simple decision table helps:
| Question | Use the snapshot when | Use the live value when |
|---|---|---|
| How is the fee calculated? | The agreement fixes the fee at signing | The agreement adjusts fees as amounts change |
| How is progress measured? | Progress is judged against the starting point | You only need the current position |
| What goes in the header? | Users need the original reference, such as the original account or amount | Users need the current status |
| What drives commissions? | Commission is earned on the signed value | Commission follows actual revenue over time |
| What do forecasts use? | Rarely | Almost always |
Often the best answer is to show both side by side. For example, a service screen can show the original and current balance next to each other, so users see what changed at a glance.
In Salesforce, a snapshot is usually a regular field populated by automation at a key moment:
For trends over time, such as pipeline or balances week by week, Salesforce reporting snapshots can save a report's results on a schedule into a custom object. That's a different job from a per-record at-signing field, and many orgs use both.
HubSpot follows the same pattern with different tools:
Many agreements cover a set of items: products, accounts, locations or balances. Customers add and remove items over time, and each change moves the live total. The snapshot shouldn't move with it, but you still need a clear record of what changed.
A practical pattern has three parts:
Also decide who can change items after an agreement goes out. If salespeople can edit the item list after sending an agreement but before signature, capture the snapshot at signature, not at sending.
Salesforce field history tracking and HubSpot property history both show how a value changed over time. They're valuable for audits and investigations. But they're awkward to calculate from, can be limited in which fields and how long they're kept, and require someone to reconstruct the value on a given date.
A dedicated snapshot field gives you the number directly, on the record, ready for formulas and reports. Keep history for accountability. For more on that side, see our guide to building audit trails in your CRM.
Vantage Point helps businesses design CRM data models that keep commitments and current reality separate. Our Salesforce implementation and advisory team and HubSpot implementation team define snapshot fields, build capture automation and align reports with the agreed rules. We've completed 400+ engagements for 150+ clients, with a 4.71/5.0 average engagement rating and 95% client retention. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
If fees, commissions or progress measures depend on numbers that keep changing, it's time for a review. Vantage Point can map your calculations and set up snapshot fields that hold. Talk to Vantage Point about your CRM data model.
A snapshot field stores a copy of a value at a specific moment, such as contract signing, and doesn't change afterward. It preserves what was agreed even when the live value moves.
It depends on your agreement. If the fee is fixed at signing, calculate it from a locked at-signing field. If the agreement adjusts fees as amounts change, use the live value, and document the rule.
No. Formula fields recalculate whenever their inputs change. Use a regular field populated by automation at the signing event, then lock it.
Create a standard field for the at-signing value, populate it with a record-triggered flow when the record reaches the signing stage, and lock it with validation rules or field-level security.
Create a custom property for the at-signing value and use a workflow triggered by the deal stage to copy the live value into it. Restrict who can edit the property afterward.
Field history shows how values changed, which helps audits. But it's awkward to calculate from and may be limited in scope, so a dedicated snapshot field is better for fees, commissions and reports.
Reporting snapshots save a report's results on a schedule into a custom object, so you can report on trends over time. They complement per-record at-signing fields rather than replacing them.