The B2B Enrichment Data Dictionary: Fields, Entity Levels, and Null Values

TL;DR: B2B enrichment commonly adds person, company, employment, location, technology, and behavioral fields. Every field needs a definition, entity level, data type, provenance, observed time, allowed null reasons, and overwrite policy. A blank value must never silently mean false, zero, unchanged, or not applicable.

What types of data do B2B enrichment tools typically provide?

B2B enrichment tools supplement an existing record with attributes used for identity, segmentation, routing, prioritization, personalization, or measurement. Common field families describe a person, a company, the employment relationship between them, relevant technology, business location, and observed behavior or signals.

Field names can look similar while carrying different meanings. Company size may refer to global employees, a regional estimate, or a categorical band. A job title may be observed text, a normalized function, or an inferred seniority. The data dictionary should make those distinctions explicit.

Assign the correct entity level

An entity level tells the system what the field describes. Person email belongs to a person, industry usually belongs to a company, and job title belongs to the relationship between a person and a company. Attaching relationship data directly to the person can preserve an old title after a job change.

Define field types and units

• Text: specify normalization, casing, allowed characters, and whether the value is observed or generated.
• Enumeration: publish the allowed values, mapping rules, and an explicit unknown state.
• Boolean: reserve true and false for known states. Use null when the fact was not established.
• Number: define unit, precision, range, and whether the value is exact, estimated, or bucketed.
• Date and time: identify time zone and distinguish event time, observed time, and sync time.
• Array: define ordering, deduplication, maximum size, and whether an empty array differs from null.
• Reference: identify the target entity and behavior when the referenced record is merged or deleted.

Treat null as a governed state

A null value should mean that the system does not have a usable value under a documented condition. It should not be used interchangeably with false, zero, empty text, not applicable, redacted, unchanged, or lookup failed.

Set overwrite and merge rules

For each field, state whether enrichment may fill only blanks, replace stale values, append an observation, or require manual approval. A current CRM owner or verified customer-provided field may have higher authority than an external estimate. A timestamp alone should not decide authority.

• Fill-if-empty: safest for customer-maintained fields with no current value.
• Replace-if-stale: requires a freshness definition and a source-authority check.
• Append observation: best for events, technology detections, and changing relationships.
• Hold on conflict: appropriate when an incorrect value changes routing, eligibility, or compliance.
• Clear on invalidation: preserves the reason a former value must no longer be used.

Give every field an operating contract

A data dictionary becomes executable when each field includes an owner, business purpose, source authority, update trigger, allowed consumers, and failure behavior. Without those attributes, two systems may share a field name while applying different definitions or overwriting each other.

Version field definitions when meaning changes. If a provider changes an industry taxonomy or a team replaces employee count with a size band, historical comparisons may no longer be like-for-like. Keep the transformation version and effective time so reports and workflows can explain the transition.

Retire fields deliberately. Identify every downstream consumer, stop writes, preserve required history, migrate references, and monitor for continued use. Deleting a visible CRM property without removing hidden workflow dependencies can create silent nulls and routing failures.

Validate the dictionary before activating data

Pick representative records and test every critical field through ingestion, mapping, conflict resolution, CRM write-back, and deletion or invalidation. Confirm that the destination field preserves the intended type and entity. Review null distributions by source and status, not only overall completeness.

Stop activation when a field lacks an owner, its definition changes by source, entity identity is unresolved, provenance is missing, or null states are collapsed in a way that changes eligibility or routing.

How Unify fits the enrichment model

Unify describes a company and contact data workflow that supports prospecting, enrichment, and enrollment. Its waterfall approach can query sources in sequence, but customers should still define field authority, entity level, null handling, and CRM overwrite behavior.

A connected workflow is most useful when the data dictionary travels with it. Store the source and observed time needed to explain why a record qualified, which value was selected, and what should happen when that value later changes.

Start using Unify to connect enrichment data with governed outbound actions.

Frequently asked questions

What types of data do B2B enrichment tools provide?

Common families include person, company, employment, technology, location, and behavioral or signal data. Exact fields and definitions vary by source.

What does null mean in enrichment data?

Null should mean the value is unknown or unavailable under a documented reason. It should not silently mean false, zero, not applicable, or unchanged.

Why assign an entity level to every field?

Entity levels prevent values from being attached to the wrong person, company, office, domain, or relationship.

Sources

• What Is Data Enrichment?, IBM, accessed September 8, 2026.
• What Is Data Lineage?, IBM, accessed September 8, 2026.
• Unify Products | B2B Company & Contact Data, Unify, accessed September 8, 2026.

‍