ListarProductsPricingToolsSign in

The CRM field schema for mobile enrichment

Updated

Almost every enrichment integration writes one thing into your CRM: the number. That is why, six months later, nobody knows where it came from, whether anyone verified it, or why the same record was enriched three times.

Seven properties are needed. Two carry the data, three carry the evidence, and two carry the state of the process. The last two decide next month's invoice, and they are the ones no vendor writes for you.

The seven properties

Property Type Why it exists
verified_mobile Text, international format The number itself. In E.164, not a local format, so it stays dialable from anywhere
line_type Picklist: mobile, landline, VoIP Decides call routing and, depending on jurisdiction, which legal regime applies
person_attachment Picklist: confirmed, not confirmed, not checked The only property that answers the question that matters: is this line this person's
verified_date Date An eighteen-month-old verification is a historical record, not a current fact
data_source Text The first thing asked for when someone wants to know where their number came from
enrichment_status Picklist: found, not found, not attempted, error Stops you replaying a record forever when there is nothing to find
last_attempt_date Date Lets you set a cadence instead of re-firing on every record edit

The last two have nothing to do with data quality and everything to do with your budget. Without them your trigger condition cannot tell a never-processed record from a processed-with-no-result record, so it retries, so it pays.

Why almost nobody writes them

We read the CRM integration documentation of the main vendors in this category in November 2026. None publishes the schema of properties written back.

What the pages describe is the mechanism: the connection, the trigger, the fact that data "is appended" to the record. What they do not describe is which properties, with which types, and which allowed values.

The practical consequence is that you discover the schema after installing, by looking at what appears on a record. And because the properties are usually created automatically by the integration, you inherit names and types you did not choose, in a CRM where a badly typed field is painful to correct later.

So ask first: which properties do you write, of which type, with which allowed values.

The three evidence properties, and what they are for

These are not for calling. They are for the day someone asks you to account for something.

data_source and verified_date answer a prospect who wants to know where their number came from, and a DPO who wants provenance per record. Under the UK's register-screening obligations and the GDPR's Article 14 duty to say where data came from, you can only answer if the information is on the record.

person_attachment is the most useful and the rarest. A number can be valid, active, correctly typed and belong to somebody else. This property is the difference between a file whose right-person rate you know and one whose rate you do not.

Note what it does not say: it does not tell you whether the line is a work line or a personal one, which is a separate question and, in some jurisdictions, the one that decides your legal regime. No vendor delivers that distinction, including us.

Modelling mistakes to avoid

Four, in order of frequency.

Overwriting the CRM's standard phone field. The enriched number needs its own property, not the field your reps fill in by hand. Otherwise you lose the human-entered value, which is often the best data on the record, and you can no longer compare the two.

Storing status in a checkbox. "Enriched: yes / no" does not distinguish found from not found from not attempted. Three states minimum, and a checkbox carries two.

Conflating verified date with collection date. A number collected in 2022 and re-verified yesterday is not a recent number. The two dates answer two different questions.

Having no opposition field. If someone asks not to be contacted, that has to live on the record and survive the next import. A separate suppression file always ends up forgotten during a re-import.

The minimum schema

If you only create three properties, create these.

Priority Property What you lose without it
1 enrichment_status You pay repeatedly for the same absence of a result
2 verified_date You never know whether you are calling fresh data
3 data_source You cannot answer a complaint

The number itself is not in that ranking because it is obvious. These three are the ones that get forgotten, and they cost, in this order: money, meetings, and a file you have to defend.

Where Listar sits

We deliver the number and its line type, and we report whether the number's attachment to the person on the record is formally proven, after the four verification layers it goes through before delivery. The verification date to write back is the date of the enrichment, which your integration already holds.

What you model on your side: enrichment status and last attempt date. Those two describe the state of your process, not the data, and no vendor can hold them for you. It is your workflow's job to write them, including when we find nothing.

On what we deliver, we publish 95% of delivered mobiles confirmed as attached to the right person, from 10,000 real calls across 100 separate files of 100 numbers each, between May and September 2026, internal, not audited, with numbers delivered as the denominator.

And the limit we share with the whole category: we do not distinguish a work line from a personal one. So do not create a property that claims otherwise.

FAQ

Which properties should I create in HubSpot for mobile enrichment? Seven: the number in international format, line type, person attachment, verified date, source, enrichment status and last attempt date. The last two describe your process and your workflow has to write them.

Why a status picklist rather than a checkbox? Because a checkbox carries two states and you need at least three: found, not found, not attempted. Without that distinction your trigger replays records where there is nothing to find.

Should the number go in the CRM's standard phone field? No. Give it its own property, so you do not overwrite your reps' manual entries and can compare the two sources.

Do vendors publish their field schema? None of the CRM integration documentation we read in November 2026 publishes the properties written back. Ask before installing, because properties are usually created automatically with names and types you did not choose.

Verified date or collection date? Both, in separate fields. A number collected four years ago and re-verified yesterday is not a recent number, and the two facts serve two different purposes.

Where should an opposition be stored? On the record, not in a separate file. A suppression that lives outside the CRM does not survive the next import, and that is the most common failure in prospecting setups.

Sources

All guides

Listar AI