A revops lead at a 60-rep B2B SaaS pulled the lead object schema from their Salesforce org last week and counted 184 custom fields, 71 of them unused in the past 12 months. Half were duplicates of standard fields the previous VP of Sales did not trust. Strkr ships a lead format of 42 canonical fields plus typed custom fields so the record is scannable, the reports work, and the schema does not sprawl.
Lead format is the layer where every CRM accumulates technical debt. The first VP of Sales adds a few custom fields, the next one adds more, enrichment vendors push data into their own fields, and five years later the lead object has 180 columns and nobody can tell a Boolean from a text field. The six pains below are what the sprawl looks like in practice.
Every CRM over 3 years old has a bloated lead object. Fields added for a one-time campaign stay forever, enrichment vendors drop fields into their own namespace, and the field inventory crosses 150 columns on most mid-market orgs. The record UI becomes unscannable. Strkr starts with 42 canonical fields and adds typed custom fields with explicit retirement rules.
A budget range field typed as free text gets filled with "80k", "$80,000", "around 80", "~80K USD", "80 to 100", and 18 other variations. The field cannot be queried, scored, or rolled up. Strkr types the field as a typed range with explicit units so every value is machine-readable while still rep-friendly.
A source field that accepts any string ends up with "Google", "google ads", "Google Ads", "SEM", "Paid Search", "Google - SEM" as six different values for the same source. The attribution report rolls up incorrectly. Strkr types source as a controlled vocabulary with UTM parameter capture so the field is clean on write.
Consent for GDPR, CCPA, CASL, and LGPD often lands in a notes field or a Boolean without versioning. The compliance review asks "which consent language did the prospect agree to on March 14, 2024" and the answer is a shrug. Strkr types consent with versioning, timestamp, and withdrawal state as first-class fields.
Legacy CRMs separate lead and account objects by default, so a lead for an existing customer sits on the lead object without linking to the account. The AE working the account cannot see the inbound without a manual match step. Strkr links lead-to-account on write when a match exists so the record carries context.
Clearbit writes company_size, ZoomInfo writes zi_company_size, Apollo writes apollo_hc_bucket, and the human-entered field is just company_size_manual. The report has to coalesce six fields to one. Strkr types enrichment data into canonical fields with vendor-source attribution so one field holds the truth and the vendor lineage is auditable.
The nine cards below describe the field groups that make up a clean lead format. Each group has typed fields with validation so the record stays queryable at scale.
Identity fields are first_name, last_name, email (validated against MX records on write), phone (E.164 formatted with country detection), and job_title. Email and phone validation runs inline so bad data never lands. The field format matches what nurture tools, outbound dialers, and compliance checks expect.
Company fields are company_name, company_domain (the canonical identifier), industry (NAICS or SIC coded), employee_count_tier, revenue_tier, hq_country, and account_id (linking to the Strkr account object if a match exists). Enrichment vendors populate these fields through a canonical shape rather than their own namespace.
Source attribution captures utm_source, utm_medium, utm_campaign, utm_term, utm_content, referrer_url, landing_page_url, first_touch_source, first_touch_campaign, last_touch_source, and last_touch_campaign. The first-touch and last-touch values persist across the lead lifetime so the attribution model has clean source data.
Lifecycle fields are lifecycle_stage (new, mql, sql, opportunity, customer, disqualified), lead_status (contacting, nurturing, qualified, closed), owner_user_id, score (0 to 100), score_last_updated_at, and routing_rule_id. State transitions log to history so the lead progression is auditable.
Consent fields are marketing_consent (Boolean plus timestamp plus language_version), email_consent, phone_consent, sms_consent, consent_capture_source (which form, which page, which campaign), and consent_withdrawn_at. CCPA do-not-sell, CASL, LGPD, and GDPR all run on the same typed consent model.
Engagement signals aggregate from product telemetry, email tool, website analytics, and call logging. Fields include email_opens_last_30d, email_clicks_last_30d, pages_viewed_last_30d, pricing_page_viewed (Boolean), form_fills_total, calls_connected, and calls_booked. The signals feed scoring and routing.
Qualification data lives in structured fields rather than free-text notes. BANT fields: budget_range, authority_level, need_tier, timeline_quarter. MEDDIC fields: metrics_captured, economic_buyer_identified, decision_criteria, decision_process, pain_identified, champion_identified. The rubric runs on the fields.
Custom fields support typed primitives (text, number, boolean, date, datetime, enum, multi-enum, email, phone, URL, currency, percentage) plus structured types (address, person, account_reference, user_reference). Retention rules let fields auto-retire after 12 months unused so the schema stays clean.
Audit fields track created_at, created_by, updated_at, updated_by, and field-level change history with user attribution. Enrichment vendor provenance tags every enriched field with the source vendor and timestamp. The audit trail satisfies SOC 2 and GDPR Article 15 (right of access) requirements without a custom report.
The six anti-patterns below are the common lead format mistakes that create technical debt. Each one is fixable with a typed field and a validation rule.
A free-text budget field creates a column that cannot be sorted, filtered, or rolled up. Strkr types budget as a currency range field with explicit units. The rep enters a range (50,000 to 100,000 USD) and the system handles the display, the comparison, and the report.
A timeline field as free text accepts "soon", "near-term", "within 90 days", and "end of year" as four different ways to say the same thing. Strkr types timeline as an enum (this_quarter, next_quarter, next_6_months, next_12_months, undecided) so the forecast report is queryable.
Custom fields added for a campaign in 2019 remain on the schema in 2026 even though nothing writes or reads them. Strkr custom fields support usage tracking (last-written-at, last-read-at) and auto-retirement rules so dead fields do not accumulate.
A single Boolean for "marketing consent" fails every compliance review because the auditor asks which consent language the prospect agreed to and when. Strkr consent fields capture the consent language version, the capture source, the capture timestamp, and the withdrawal state so the audit answer is one query.
A score field with a number but no explanation of what drove the number creates a trust problem. The sales manager cannot calibrate, the rep does not know why the score is high, and model drift goes undetected. Strkr exposes the top three drivers of every score inline so the number is explainable.
Legacy CRMs let three leads for the same company sit on the lead object without linking to the account. The AE working the account sees none of the inbound. Strkr lead-to-account matching on domain plus firmographic fingerprint runs on write so the account view shows the full picture.
Migrating a legacy lead object to a clean format is a 6-step motion. The sequence below works at mid-market scale (10,000 to 500,000 lead records) with limited downtime.
Audit every field for the past 12 months: how often is it written, how often is it read, and by what systems. Fields with zero writes and zero reads flag for retirement. The audit typically retires 30 to 50 percent of custom fields on a legacy org without affecting any production flow.
Free-text fields that encode structured data (budget, timeline, industry, size) convert to typed fields with controlled vocabularies. The conversion runs with a text-to-enum mapping that handles common variants. Dirty historical data normalizes on migration so the new schema is clean from day one.
Source attribution fields rebuild on a canonical UTM-based taxonomy with explicit mappings for pre-UTM historical data. First-touch and last-touch populate from the earliest and latest activity records. The attribution report regains fidelity after the rebuild.
Consent fields reconcile against the historical consent language the prospect saw on each form submission. The version mapping comes from the form change-log. Prospects without a confirmable consent get a re-consent email with the current language. Compliance posture improves without a legal fire drill.
A one-time account-matching sweep links orphaned leads to existing accounts on domain, firmographic fingerprint, and fuzzy name match. The match rate typically runs 20 to 40 percent on legacy orgs that never ran lead-to-account matching before. AE account views become complete.
Reports and dashboards rewire from the legacy fields to the new typed fields over a 2-week transition. The legacy fields stay read-only for 90 days as a reference. Report writers verify every output against the previous period before the legacy fields deprecate.
The lead object on a legacy Salesforce or HubSpot org tends to accumulate custom fields over time. Here is the head-to-head when the question is schema cleanliness.
| Feature | Strkr | Legacy CRM field sprawl |
|---|---|---|
| Starting field count | 42 canonical fields | 35 to 60 fields |
| Typical field count after 3 years | Stays near 60 with retirement rules | 120 to 200 custom fields |
| Free-text structured fields | Typed enums and ranges | Common across orgs |
| Source attribution typing | Controlled vocabulary + UTM | Free-text in most legacy configs |
| Consent versioning | Native with timestamp and source | Boolean, often missing version |
| Field usage tracking | Writes and reads logged per field | Not available natively |
| Auto-retirement rules | Native | Manual cleanup |
| Enrichment vendor namespacing | Canonical fields with provenance tag | Vendor-specific namespaces |
| Lead-to-account matching | Native on write | Manual or add-on |
| Audit trail per field | Native | Field history add-on |
Five production rebuilds. Each one started with a bloated legacy object and ended with a clean typed schema.
A 60-rep B2B SaaS on Salesforce had 184 fields on the lead object. The usage audit found 71 fields with zero writes in 12 months and 42 fields that duplicated standard functionality. The rebuild shipped 58 fields total (42 canonical plus 16 typed custom) with no historical data lost. Report load times dropped 40 percent because the queries scanned a smaller row.
A B2B services firm with EU prospect data failed a GDPR audit because consent was captured as an unversioned Boolean. The rebuild re-typed consent with language versioning, capture source, timestamp, and withdrawal state. The re-consent campaign recovered 68 percent of prospects. The second audit review passed cleanly.
An enterprise sales org had six company-size fields from Clearbit, ZoomInfo, Apollo, HG Insights, Dun & Bradstreet, and manual entry. The rebuild collapsed to a canonical employee_count_tier field with vendor provenance tags. Reports became consistent, the sales manager stopped seeing contradictory data on the same account, and the enrichment contracts consolidated to two vendors.
A mid-market B2B org had 47 distinct source string values on the lead object. The rebuild typed source as a 12-value enum (direct, organic, paid_search, paid_social, email, referral, partner, event, outbound, chat, content_download, other) with UTM mapping. The marketing attribution report regained CFO trust and the paid-campaign ROI calculation became accurate.
A sales org running BANT qualification kept the BANT answers in a free-text notes paragraph. The rebuild typed BANT as four structured fields (budget_range, authority_level, need_tier, timeline_quarter) with the free-text notes preserved for context. Pipeline queries by qualification quality became possible for the first time.
Start a 14-day trial with the canonical lead schema, typed fields, versioned consent, and account linkage enabled. Retire the 184-field sprawl without losing a byte of history.
Lead format is the data schema of a lead record: which fields exist, how they are typed, what validation runs on them, and how they relate to other records (accounts, opportunities, activities). Format matters because every downstream capability (scoring, routing, segmentation, reporting, compliance) depends on the schema being clean and queryable. A bloated or free-text-heavy lead object produces unreliable reports, inconsistent scoring, and audit failures.
A canonical lead schema needs roughly 40 to 60 fields covering identity (5 to 8 fields), company (6 to 10), source attribution (8 to 12), lifecycle state (5 to 7), consent and compliance (6 to 10), engagement signals (6 to 10 rolled up), and qualification (4 to 10 depending on framework). Custom fields can extend the schema but should carry retirement rules so the field count stays manageable. Strkr starts at 42 canonical fields and most orgs land under 60 total after 3 years.
Free-text fields for structured data (budget, timeline, industry, company size) create columns that cannot be sorted, filtered, aggregated, or compared reliably. The same value gets entered many different ways: "80k", "$80,000", "around 80", "80 to 100". The field becomes useless for reporting or scoring. Typed fields with controlled vocabularies (enums, ranges, currency amounts) solve the problem on write and keep the record queryable.
Consent fields capture four pieces of data: a Boolean for consent state, the language version the prospect saw, the capture source (which form, which page, which campaign), and the capture timestamp. Withdrawal captures as a separate timestamp. The versioning matters because consent language updates over time and the audit question is which version the prospect agreed to. CCPA do-not-sell, CASL (Canadian), LGPD (Brazilian), and GDPR all run on the same typed consent model.
Yes with explicit retirement rules. Custom fields in Strkr support typed primitives (text, number, boolean, date, datetime, enum, multi-enum, email, phone, URL, currency, percentage) and structured types (address, person, account_reference). Each custom field has a last-written-at and last-read-at timestamp. Retirement rules can auto-retire fields that have not been written for 12 months. The field inventory stays under control over time.
Migration runs in six phases: field usage audit (identify dead fields), free-text typing (convert strings to enums and ranges), source attribution rebuild (clean the UTM taxonomy), consent reconciliation (backfill consent language versions), account linkage sweep (match orphaned leads to accounts), and report rewiring (point dashboards at the new fields). Legacy fields stay read-only for 90 days during the transition. Historical data normalizes against the new schema so reports work across the boundary.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
