CRM field bloat is a screen problem before it is a data problem. Hundreds of fields on a record, about a dozen in real use. Here is the hide-first method we use to give every team a short record in week one, then clean up the rest without breaking anything.
Joe LaGrutta, Founder, JayOh
13 min read · Updated November 2026
↗ 700 fields shown, 12 used. That gap is the whole problem.
Joe LaGrutta, Founder, JayOh
Your CRM doesn't have a data problem. It has a screen problem. Hundreds of fields on the contact record. Most teams use about a dozen. Reps scroll past the noise to find the fields that matter. Eventually they stop looking, and the important fields get skipped along with the useless ones. Each field made sense to someone once. Nobody removes them, because deleting feels risky. You don't have to delete first. Start by hiding. What we do in week one: 🔸 List the fields each team actually uses, by role 🔸 Build record layouts per team showing only those fields 🔸 In Salesforce, use Dynamic Forms visibility rules to show fields by stage 🔸 In HubSpot, customize the record sidebar and middle column per team Reps see a short record instead of a long scroll. Fill rates on the fields that matter tend to rise without a single training session. Then cleanup gets easy. Anything no layout shows, no report reads and no workflow touches is a deletion candidate. You can prove nobody will miss it before it goes. A record that shows everything gets nothing filled in.
Nobody decides to build a 700-field record. It accumulates one reasonable request at a time, and nothing in the system ever removes anything.
Each field made sense to someone once: a campaign, a board question, a one-off report. Adding takes two minutes. Removing feels risky, so nobody owns it.
SDRs, AEs, CS and finance all open the same record and scroll past each other's fields. The record shows everything, so the critical fields get skipped along with the useless ones.
A migration or a new data tool brings every source field along "just in case." Enrichment and sync tools add dozens more that nobody on the team reads.
HubSpot shows fill rate and usage for every property. Salesforce shows where a field is used. Neither gets reviewed until budget season or a migration forces it.
Teams think the fix is a big deletion project, so they postpone it. The faster, safer move is to change what each person sees first.
If you have already lived through the workaround version of this, our post on CRM technical debt covers how temporary fields become permanent. This post is about the fix.
Strong CRMs show each rep 25 fields or fewer by default and keep the decision-critical ones above 90% filled. The total field count matters less than what each person has to scroll past.
| Metric | Weak | Acceptable | Strong |
|---|---|---|---|
| Fields visible on a rep's default record view | 60+ | 25–60 | 25 or fewer |
| Custom fields on a core object (Salesforce Enterprise cap is 500) | 350+ (70%+ of cap) | 150–350 | Under 150 |
| Share of fields with fill rate under 5% | 50%+ | 25–50% | Under 25% |
| Fill rate on the 10–15 decision-critical fields per team | Under 70% | 70–90% | 90%+ |
| Hours per week a team member spends hunting for basic information | 13+ (the survey average) | 5–13 | Under 5 |
Sources: Salesforce edition limit from Salesforce Help, Custom Fields Allowed per Object (2026). Hours-per-week average from Validity, State of CRM Data Management (2025, 602 respondents). Weak/acceptable/strong bands are JayOh ranges from CRM audits, not survey results.
Change what people see in the first 30 days. Use the next 60 to prove which fields nobody needs. Only then remove anything.
Role layouts go live. No data changes.
Tag archive candidates. Owners confirm.
Export values, archive, log every change.
What: one row per field with fill rate, last update and every place it is used. Why: you cannot argue about fields without evidence, and memory is wrong about half the time.
HubSpot: Settings > Properties > Export all properties. The file includes fill rate and usage and arrives by email. Salesforce: export the field list from Object Manager, build a report that counts non-blank values per field, and check "Where is this used?" on anything referenced by automation.
What: a 30-minute session per team (SDR, AE, CS, finance, marketing ops) asking which fields they read, which they write, and at what stage. Why: a field that matters to finance at renewal is noise to an SDR on first touch.
Build a simple role x field matrix in a sheet: rows are fields, columns are teams, cells are R (read), W (write) or blank. Most fields end up with one or zero marks.
What: the fields that drive routing, forecast, comp, handoff and board reporting. Why: these are the ones that must be above 90% filled, so they go at the top of every layout.
Test each candidate: "If this field were blank, what decision would go wrong?" If nobody can name one, it is supporting, not critical.
What: one record view per team. Why: reps see their fields first, and the rest disappear without being deleted.
Settings > Data Management > Objects > [object] > Record Customization > Create team view, then Assign teams. Team views need a Professional or Enterprise subscription. Clone the default view first, because a new team view starts from the system default. Put critical fields in a property card in the middle column, and use the card's "Set conditional logic" to show a card only when it applies (for example, a Renewal card only when lifecycle stage is Customer). Up to 50 cards and 5 tabs are allowed, which is far more than you should use. Then customize record previews so the preview sidebar matches.
What: Lightning record pages where fields show by stage, profile and device. Why: one page can serve every team without anyone scrolling past fields they never use.
In Lightning App Builder, select the Record Detail component and choose Upgrade Now to migrate the page layout into Field Sections. Add visibility rules on each section: record data (Stage equals Negotiation), user (Profile or Permission) and device. Assign pages by app, record type and profile. Dynamic Forms works on most LWC-enabled standard objects and custom objects, but not on Tasks, Events or Products, and the Opportunity create window still uses the page layout.
What: remove low-value fields from every layout and keep the data intact. Why: hiding is reversible in minutes, and it shows you who actually misses what.
Announce it in one message: "Your record is shorter. If something you need is gone, reply here." Log every request in a sheet. In our experience, requests are rare, and each one tells you about a field that really is needed.
What: a list of fields that no layout shows, no report reads and no automation touches. Why: this is the proof that nobody will miss them.
Rule: fill rate under 5% or no update in 12 months, zero references in workflows, flows, Apex, reports, lists, forms or validation rules, not written by an integration. In HubSpot, the Archive panel lists "Assets preventing archiving" for each property. Send the list to each field's owner for a yes or no.
What: archive or delete confirmed candidates in small batches. Why: small batches make any surprise easy to trace.
HubSpot: archived properties can be restored for 90 days, then they are permanently deleted. Salesforce: export field values first, then delete. Deleted custom fields can be restored for 15 days. Record every change (who, what, why, date) in a change log.
What: a short intake for every new field request. Why: without one, bloat comes back within two quarters.
Required on every request: owner, purpose, the report or automation that will read it, which team layout it goes on, and a review date. Add the owner and purpose to the field's description (HubSpot) or Help Text (Salesforce).
What: a weekly report on the critical fields per team and a quarterly count of fields per object. Why: the goal is better data on fewer fields, not a smaller number for its own sake.
HubSpot: a custom report with "is known" filters on each critical property, grouped by owner. Salesforce: a summary report with a row-level formula counting non-blank critical fields, grouped by owner. Re-run the full usage export every quarter.
The best cleanups change the screen first and the schema last. The expensive mistakes all come from deleting before proving.
Duplicate fields usually travel with duplicate records. If both are a problem, pair this with our CRM deduplication guide. For the rep side of the rollout, see seller adoption.
Put in your own numbers to see how much time a long record costs your team each year, and how your layout grades against the benchmark.
Estimate only: it counts scanning time, not the cost of bad data from skipped fields, which is usually larger. Grade bands: 25 or fewer fields strong, 25–60 acceptable, over 60 weak (JayOh ranges).
Paste this into your audit sheet or ticket. It is the exact rule set from steps 3, 7 and 9, so every field gets the same decision no matter who reviews it.
CRM FIELD TRIAGE: RULES AND ROLE LAYOUT SPEC
Object: ____________ Owner: ____________ Review date: ____________
1. EXPORT (one row per field)
Name | API name | Type | Fill rate | Last updated | References (workflows/flows, reports, lists, forms, validation, Apex, integrations) | Layouts | Owner
2. PROTECTED (never archive)
[ ] System fields
[ ] Written by an integration or sync
[ ] Read by routing, forecast, comp or billing logic
[ ] Referenced by Apex or an external API
3. DECISION RULES (apply in order)
KEEP AND SHOW = a team named it decision-critical, OR fill rate 70%+ and read by a report or automation
KEEP, HIDE = has references or history value, no team needs it day to day
ARCHIVE CANDIDATE= fill rate under 5% OR no update in 12 months, AND zero references, AND not protected
INVESTIGATE = anything else (low fill + active references, duplicate meaning)
4. ROLE LAYOUT SPEC (one per team)
Team: ________ Stage: ________
Critical fields (10-15, in work order): ________________________
Supporting fields (max 10): ________________________
Conditional display rule: show group ______ when ______ = ______
5. 90-DAY PLAN
Days 1-30 Hide: role layouts live, no data changes, log every "I need that field back"
Days 31-60 Prove: tag archive candidates, owners confirm yes/no
Days 61-90 Archive: export values, archive in small batches, change log updated
(HubSpot archive restorable 90 days; Salesforce deleted fields restorable 15 days)
6. NEW FIELD GATE (required on every request)
Owner | Purpose | Report or automation that reads it | Team layout | Review date
Hand Claude your HubSpot or Salesforce field export and it applies this post's rules field by field.
~/.claude/skills/crm-field-triage/SKILL.md, or under .claude/skills/ in your repo.Skills are available on Claude Pro, Max, Team and Enterprise plans. New to skills? Read how to use skills in Claude.
--- name: crm-field-triage description: Triage CRM field bloat in HubSpot or Salesforce. Use when someone shares a property or field export (fill rate, last updated, where used, layout placement) and wants to know which fields to keep, hide from layouts, archive, or investigate, plus a lean record layout per team. Applies the JayOh hide-first method. --- # CRM Field Triage You turn a raw field or property export into a decision for every field and a short record layout for each team. You follow the JayOh hide-first method: hide before you archive, archive before you delete, and never remove a field you cannot prove is unused. ## Inputs to ask for 1. The field export. HubSpot: Settings, Properties, Export all properties (it includes fill rate and usage). Salesforce: the object field list plus a non-blank count per field and the Where is this used result for any field you are unsure about. 2. The object (contact, company, deal, lead, account, opportunity). 3. The teams that use the record (for example SDR, AE, CS, Finance, Marketing Ops) and, if known, which fields each team reads or writes. 4. Any fields that feed integrations, billing, routing, forecasting or compensation. If an input is missing, list it under Missing evidence. Do not guess. ## Step by step 1. Normalize the export into one row per field: name, internal name, type, fill rate, last updated, number of references (workflows or flows, reports, lists or segments, forms, validation rules, Apex, integrations), layouts it appears on, owner. 2. Flag protected fields first: system fields, fields written by an integration, fields read by billing, routing, forecast or comp logic, and anything referenced by Apex or an external API. Protected fields are never archive candidates. 3. Classify every remaining field with these rules, in order: - KEEP AND SHOW: a team named it as decision-critical, or fill rate is 70 percent or higher and at least one report or automation reads it. - KEEP, HIDE FROM LAYOUTS: it has references or history value, but no team needs to see it day to day. - ARCHIVE CANDIDATE: fill rate under 5 percent, no update in 12 months, zero references, not on any layout a team asked for, and not protected. - INVESTIGATE: anything that does not cleanly fit, including low fill rate with active references, or duplicate meaning with another field. 4. Find duplicates: fields with the same meaning under different names (for example several lead source fields). Recommend one survivor and a merge path. 5. Build one layout per team: the 10 to 15 decision-critical fields first, grouped by stage, then at most 10 supporting fields. Note where conditional display should hide a group until a stage or lifecycle value is reached. 6. Grade the current state against the benchmarks: fields shown on the default rep view (25 or fewer strong, 25 to 60 acceptable, over 60 weak); share of fields with fill rate under 5 percent (under 25 percent strong, 25 to 50 percent acceptable, 50 percent or more weak); fill rate on decision-critical fields (90 percent or more strong, 70 to 90 percent acceptable, under 70 percent weak). These bands are JayOh experience ranges, not survey results. 7. Write the 90-day plan: days 1 to 30 hide, days 31 to 60 tag and confirm archive candidates with owners, days 61 to 90 export data and archive. In HubSpot, archived properties are permanently deleted after 90 days. In Salesforce, deleted custom fields can be restored for 15 days, so export the values first. ## Output format 1. Summary: total fields, counts per decision, the three grades, and the single biggest risk. 2. Decision table: field, decision, reason (quote the export values you used), owner to confirm. 3. Duplicates: groups and the recommended survivor. 4. Team layouts: one list per team, in display order, with conditional display notes. 5. 90-day plan with named owners where known. 6. Missing evidence: every input you needed and did not get. ## Guardrails - Quote the export as evidence for every decision. Never invent fill rates, counts or references. - Never recommend deleting a protected field or a field with any active reference. - Hiding is the default when in doubt. - Do not name the client or expose record-level data in the output. Built by JayOh (jayoh.io). Method and benchmarks: https://jayoh.io/crm-field-bloat/
Short answers to the questions we hear most in CRM audits.
Export the field list from Object Manager, build a report that counts non-blank values for each field, and check “Where is this used?” for anything that might be referenced by automation. A field with a fill rate under 5%, no update in 12 months and no references in flows, Apex, reports or validation rules is an archive candidate.
Go to Settings > Properties and use Export all properties. The export includes each property's fill rate and where it is used. When you open Archive on a single property, HubSpot also lists the assets that prevent archiving, such as workflows, forms and segments.
Hide first. Removing a field from every layout is reversible in minutes and shows you who actually needs it. Archive or delete only after 30 to 60 days with no requests, zero references and an owner's sign-off, and export the values before you delete.
Yes. On Professional and Enterprise subscriptions, go to Settings > Data Management > Objects, choose the object, open Record Customization and create a team view. Assign it to teams, and use conditional logic on cards to show them only when they apply.
Dynamic Forms move page layout fields into sections on a Lightning record page, where each section can show or hide based on record data, the user and the device. They work on most LWC-enabled standard objects and on custom objects, but not on Tasks, Events or Products.
It depends on the edition: 100 on Professional, 500 on Enterprise and 800 on Unlimited and Performance, according to Salesforce Help. Managed packages can add more, up to the object's hard limit.
In our audits, strong setups show 25 fields or fewer on a rep's default view, with the 10 to 15 decision-critical fields at the top. More than 60 is where critical fields start getting skipped.
Field bloat is not a hygiene project you schedule for next quarter. It is a design decision you make every time someone opens a record. Fix the screen in week one, prove what nobody needs, then clean up with evidence instead of nerve.
This is the same method behind the data cleanups where we have cut data errors by 90%. Our HubSpot audit and Salesforce audit frameworks start with exactly this export.
Get a field audit for your CRM
Sources: HubSpot: Customize records · HubSpot: Organize, delete and export properties · Salesforce: Dynamic Forms · Salesforce: Custom fields per object
We engineer growth systems. JayOh builds the RevOps architecture, GTM execution and data infrastructure that turn messy revenue operations into predictable pipeline for B2B SaaS and PE-backed teams.
