B2B Data Freshness: Created, Updated, and Verified Dates Mean Different Things
A B2B data timestamp establishes when a particular event happened to a particular record or field. It does not establish that the entire contact is accurate today. Created usually describes entry into a system; updated describes a recorded change; refreshed describes a retrieval or processing event; verified describes a check whose meaning depends on its method and scope.
Before calling a list fresh, identify the field you intend to use, the event behind its date, and the evidence that connects them. A recent timestamp without that context is insufficient to decide whether a person still holds a role or a phone number still belongs to them.
Which record or field does the date describe?
Start with the object. Company, person, opportunity, and activity records describe different things. A date on the company record cannot automatically certify a contact’s title. A date on a person record cannot automatically certify every related company attribute. Unify’s objects and attributes documentation explains this separation between records, attributes, and relationships.
Then identify where the date lives. A timestamp beside the whole record can describe record administration. A timestamp stored with an individual value may describe that value’s history. A timestamp on an enrichment job can describe processing. These are different units even when the interface displays them in the same format.
There is a concrete distinction in Unify’s Get record API response: created_at and updated_at appear at the record level, alongside an attributes object. That response structure alone does not establish a verification date for every attribute. Inspect the documented meaning of each field before deriving a freshness claim.
Created, updated, refreshed, and verified are different events
| Date label | What it can establish | What it cannot establish alone |
|---|---|---|
| Created | When this record entered the specified system, under that system’s definition | When the underlying fact first became true or was last checked |
| Updated | When the specified record or field changed | That every field was reviewed or the new value is correct |
| Refreshed | When the documented retrieval or refresh process ran | That the source changed, or that all records and fields were processed |
| Verified | When the stated check was performed on the stated value | That unrelated fields were checked or that the value remains correct indefinitely |
These are interpretation rules, not universal vendor definitions. Ask what starts the clock and what resets it. Importing a record, editing a field, fetching a cached response, and checking a source are distinct events. The system’s documentation or audit history must establish which event a displayed date represents.
Keep the system name attached to a creation date. “Created in CRM” and “created in the provider database” describe different histories. When data moves between them, a new destination record can retain older source values. The destination’s creation time therefore cannot substitute for the source’s observation time.
Why a recent record can contain older information
A record-level change says nothing about fields outside that change’s scope. An ownership update, a newly mapped attribute, or a synchronization operation should be interpreted according to its documented behavior. Do not infer that a title, employer, email, and phone were all checked just because the record displays a recent date.
The standard objects and attributes reference makes another useful distinction: activity timestamps describe recorded activity, while fields such as title and phone are separate attributes. Recent activity is useful context, but it does not turn an old contact detail into a newly verified one.
Job changes deserve their own evidence because the person–company association affects routing and personalization. The Champions documentation covers following advocates who change jobs. Treat a job-change observation as a reason to review the relevant association; do not extend it into a claim that every contact method has also been revalidated.
Ask what “verified” actually means
Verification is a procedure with a target, a time, and a result. Ask which value was checked, against which source or service, using which method. An email address check, a company-domain match, and a human confirmation of employment answer different questions. A result only supports the question the procedure can answer.
Record the result as well as the date. An inconclusive check performed recently is still inconclusive. A successful check of an email address does not establish the recipient’s buying authority. A phone association needs evidence about the person and number; the presence of a number in a record is not that evidence.
Also separate observation from effective time. A source can report an event after it happened. If both dates are available, preserve both and label them. If the effective date is unknown, do not manufacture it from the time your system fetched the report. Use “unknown” where the evidence stops.
Read refresh claims at their stated scope
Unify’s B2B company and contact data page describes daily partial refreshes and multi-source enrichment. “Partial” matters: a refresh cadence for a database does not mean that every field in every record was rechecked during that interval. Multi-source coverage also does not, by itself, establish when a particular value was observed.
Use AI research to investigate the specific fact that matters to the next action, and retain the supporting source where your workflow allows it. Research output still needs an identifiable claim and evidence. Do not label a value verified merely because an agent returned it.
When Plays connect research, enrichment, and outreach, define the evidence required before the next action. The workflow finishing successfully establishes execution, not universal data accuracy. Treat the acceptance rules below as a proposed operating method to test in your workspace, rather than a promise about automatic timestamp exposure.
Keep source dates separate from sync dates
A freshness interpretation can be lost during synchronization if the destination receives a value but not its meaning. Inspect whether a date is copied from the source, assigned during ingestion, or computed locally. Keep the attribute name and time zone explicit, and preserve the original source date where supported.
Unify’s HubSpot field mappings and Salesforce field mappings govern how corresponding values move between systems. Review the relevant mapping before treating a destination field as authoritative. A timestamp with an ambiguous label should remain ambiguous in reporting until someone resolves its definition.
Use the CRM integration audit guide when records disagree across systems. Trace the specific value and mapping, rather than treating whichever system has the latest record-update time as automatically correct. Retain conflicting evidence until the responsible owner decides which claim is supported.
Use a blank timestamp interpretation worksheet
Complete this worksheet from a permitted real record, its documented schema, and the source evidence available to your team. The empty cells are intentional. Do not replace missing verification evidence with a general database-refresh claim.
| Evidence to collect | Observed value or definition | Source or record reference |
|---|---|---|
| Object and record identifier | ||
| Field and current value | ||
| Displayed timestamp and time zone | ||
| Event that creates or resets the timestamp | ||
| Source observation or effective date | ||
| Verification method and result | ||
| Remaining uncertainty and required next check |
A proposed acceptance rule is to approve the interpretation only when the timestamp has a defined scope and the available evidence supports the intended claim. Otherwise, label the freshness unknown and decide whether to inspect the source, recheck the field, or avoid using that detail in outreach. Keep this decision separate from overall provider selection; the data enrichment evaluation guide addresses the broader buying decision.
Apply the rule to the fields that affect the next action. There is no single age threshold that proves every field usable. Choose review intervals according to how the field changes and the consequence of being wrong, then validate those intervals against observed errors.
Frequently asked questions
Does a newly created contact mean the data is new?
No. It establishes when that record entered the named system, subject to its definition. The contact details may have been collected earlier. Look for source observation or verification evidence before assigning an age to the underlying facts.
Does an updated date mean every field was checked?
No. Determine whether the timestamp belongs to the whole record or a particular field, and which event changed it. A record-level update cannot independently certify unrelated values.
Is a refresh date the same as a verification date?
No. Refreshing can describe retrieval or processing. Verification describes a check with a defined method and result. Ask what happened and which values were included before interpreting either date.
What should accompany a verified date?
The field and value checked, the method, the result, the source, and the applicable time zone or time convention. Preserve uncertainty when the procedure cannot establish the fact you need.
Does Unify expose verification timestamps for every field?
The public sources cited here do not establish uniform field-level verification timestamp exposure. Inspect your actual object attributes and available source evidence. Do not infer that capability from record-level timestamps or a general refresh cadence.
Glossary
- Timestamp scope: The record, field, event, or process to which a date applies.
- Observation time: When a source observed or recorded a fact.
- Verification event: A documented check of a specified value using a specified method.
