What: Using Breeze Assistant to audit the custom properties on your Contact, Company, and Deal objects, then producing a structured property rationalisation plan that consolidates overlaps, retires stranded fields, enforces a naming convention, and sets a governance model going forward - without quietly breaking the workflows, reports, and integrations that depend on them.
Prompt of the week:
This is not a generic “tidy up your properties” exercise. This is about asking Breeze to look at your portal’s actual custom property set - the fill rates, the workflow references, the naming inconsistencies, the semi-orphaned fields from the 2023 campaign nobody remembers - and return a plan that tells you exactly what to consolidate, what to rename, what to retire, and in what order, so nothing downstream breaks.
Property sprawl is the single most common complaint in both the HubSpot and Salesforce communities, and it is also the most quietly damaging. Every week somebody posts a variant of “we have 47 contact properties nobody can explain”, “how do I find properties that aren’t being used”, or “we have three fields that all seem to store industry.”
The specifics change; the pattern does not.
The reason this happens is entropy. Every new campaign, integration, rep-specific request, or “can we just add a field for” moment adds another custom property. Nobody ever has time to go back and retire the ones that stopped earning their keep.
Within 18 months of go-live, most portals have accumulated a property list that is 30-50% noise, and the signal-to-noise ratio keeps getting worse because every new team member learns the portal by copying what is already there.
The damage is cumulative and mostly invisible. Segmentation gets unreliable because two properties “look” like they should work the same way but do not. Reports surface different answers depending on which field the analyst picked. Forms collect data into properties that nothing downstream is reading. And now, with Breeze agents reasoning over the portal, the noise becomes an active liability - the agent will happily use a stranded, inconsistent property as if it were gospel, because it has no way to know it is not.
That is what this prompt does. It forces the audit work everyone agrees is important and nobody has time for.
Prompt structure
Paste this into Breeze Assistant and make sure CRM data access is enabled in your AI settings so Breeze can reference your portal’s properties, workflows, lists, and reports:
Role: You are a HubSpot Property Governance Specialist. You know
how HubSpot properties drift over time, and you understand how to
rationalise a sprawling property list without breaking the
workflows, reports, and integrations that depend on it.
Task: Audit the custom properties on our Contact, Company, and
Deal objects and produce a Property Rationalisation Plan that
consolidates overlaps, retires stranded fields, enforces a naming
convention, and sets a governance model going forward.
Context:
- Company: [COMPANY NAME]
- Industry: [INDUSTRY]
- HubSpot tier: [e.g., "Marketing Hub Pro + Sales Hub Enterprise"]
- Portal age: [YEARS since go-live]
- Approx. custom property count on Contact / Company / Deal:
[e.g., "Contact ~180, Company ~60, Deal ~40"]
- Primary use cases depending on custom properties:
[e.g., "segmentation, lead scoring, rep routing, board reporting"]
- Teams with property-creation permission currently:
[e.g., "Admins only" / "Admins + marketing ops" / "Everyone"]
- Active integrations writing to custom properties:
[e.g., "Salesforce sync, Zapier, custom API to Business Central"]
Audit the following:
1. OVERLAP & DUPLICATION
Identify custom properties that duplicate or near-duplicate an
existing HubSpot default or another custom property. Typical
offenders:
- "Industry" vs. custom "Sector" or "Business Type"
- "Lead Source" vs. "Original Source" vs. custom "How did you
hear about us?"
- "Job Title" vs. custom "Role" or "Seniority"
- Multiple "Last Contact Date" or "Last Activity" style properties
- Multiple lifecycle or status fields running in parallel
For each overlap, recommend the SURVIVING property, the fields to
retire, and the logic for merging any values that would otherwise
be lost.
2. STRANDED FIELDS
Identify properties that meet ALL of the following criteria:
- Less than 5% fill rate across records
- Zero references in any active workflow
- Zero references in any saved list
- Zero references in any active report
- No description, or last-modified date older than 12 months
For each, recommend: RETIRE / ARCHIVE / KEEP WITH REASON.
3. NAMING CONVENTION
Review naming patterns across the custom property set and flag:
- Inconsistent casing (Title Case / snake_case / camelCase mixed)
- Inconsistent prefixing (no prefix / department prefix /
source prefix)
- Unclear, abbreviated, or dated names
(e.g., "LS_Src", "temp_flag_2022", "x_custom_3")
- Properties whose internal name and display label have drifted
Recommend a single naming convention and a rename plan for
non-conforming properties, noting which renames will break
integrations and need coordinated change control.
4. FIELD TYPE HEALTH
Flag properties where the field type itself is creating data
quality problems:
- Free-text fields that should be dropdowns
(country, industry, lead source, seniority)
- Single-line text fields routinely used for multi-value data
- Dropdowns with 30+ options and obvious synonyms
(candidates for consolidation)
- Number fields storing values that should be formatted
(currency, percentage, duration)
- Date fields used as de facto booleans
5. OWNERSHIP & GOVERNANCE MODEL
Recommend:
- Who should hold property-creation rights going forward
- A property request process — what info must be captured before
a new property is created: purpose, owner, object, field type,
allowed values, expected fill rate, downstream use
- A naming convention standard to enforce
- A quarterly property review cadence
Constraints:
- Do NOT recommend deleting any property without a proposed archive
step first (rename to "ARCHIVE_[property]_YYYYMM" and hide from
layouts) so the data is preserved for at least 90 days
- Flag any property used by an active integration as
DO NOT TOUCH WITHOUT CHANGE CONTROL
- Every rename recommendation must list the downstream artefacts
that will need updating (workflows, lists, reports, integrations,
forms, email tokens)
- If the fill rate, usage, or modification date for a property is
not visible from the current context, state:
"SIGNAL MISSING: [what needs checking manually]"
- Keep the plan practical — recommend a rolling retirement cadence
(e.g., 10–20 properties per month), not a big-bang cleanup
Output format:
### I. PROPERTY INVENTORY SUMMARY
{Total custom property count by object, % stranded, % with overlap,
biggest single risk identified}
### II. OVERLAP CONSOLIDATION PLAN
| Object | Duplicate Properties | Surviving Field | Action |
| Downstream Impact |
### III. STRANDED FIELD RETIREMENT LIST
| Object | Property | Fill Rate | Last Modified | Recommendation |
### IV. NAMING CONVENTION & RENAMES
| Old Name | Proposed Name | Breaking Change? | Coordination Needed |
### V. FIELD TYPE FIXES
| Property | Current Type | Recommended Type | Migration Notes |
### VI. PROPERTY GOVERNANCE MODEL
{Proposed creation permissions, request process, naming standard,
quarterly review cadence}
### VII. ROLLING RETIREMENT PLAN
{Ordered list of properties to retire by month, with owner and
success criteria — e.g., "Month 1: archive 15 stranded Contact
fields, owner: CRM Admin, success criteria: zero drop in report
outputs"}
Why this prompt works - and how to adapt it
This prompt is doing something harder than it looks. Property governance is the unglamorous middle child of CRM work - less visible than a new campaign, less satisfying than closing a deal, less urgent than a broken workflow. It is also the single highest-leverage piece of admin work anybody can do, because every report, every workflow, every AI agent, and every piece of segmentation downstream depends on the property model being coherent.
A few things to note about how it's constructed:
The Context section is not optional. A five-year-old Enterprise portal with Salesforce sync, 180 contact properties, and tribal knowledge in four different teams needs a very different plan from a two-year-old Starter portal with 40 properties and a single admin. The governance model at the end of the output is entirely driven by what you put in Context — skip it and you will get generic advice.
The “archive before delete” constraint is the most important line in the prompt. The most common failure mode in property cleanup projects is someone deciding a field “looks unused,” deleting it, and discovering two weeks later it was feeding a quarterly board report nobody mentioned. The constraint forces Breeze to recommend a reversible path — rename to ARCHIVE_, hide from layouts, revisit after 90 days — rather than destructive action. Keep it in.
The “SIGNAL MISSING” flag keeps the output honest. Breeze can see a lot about your portal, but it cannot see everything — background integrations, tribal knowledge about why a weird property exists, downstream uses in third-party tools. When a recommendation depends on something Breeze cannot verify, you want it flagged so you can check, not glossed over. A flagged unknown is more useful than a confidently wrong suggestion.
Listing active integrations in Context changes the output. If you tell Breeze that certain properties are written to by Salesforce or a BC integration, it will treat those as DO NOT TOUCH WITHOUT CHANGE CONTROL and route the rationalisation effort around them. If you skip it, you risk getting a plan that looks perfect on paper and blows up an integration in production.
The rolling retirement plan at the end is the whole point. A flat list of 120 properties to clean up is worse than useless; it just makes people freeze. A month-by-month plan with 10–20 properties per batch, each with an owner and a success criterion, is something you can actually execute — and report progress on to leadership.
Adapting it for your portal:
If you run HubSpot and Salesforce in parallel, add this line to the Context section so Breeze knows which fields are off-limits to rename or retire:
If you already have a scoring model but it feels stale or unreliable, add this line to the Context section:
Our HubSpot portal syncs with Salesforce via [HubSpot native /
third-party connector]. The following properties are part of the
sync and cannot be renamed or retired without coordinated change:
[LIST].
Breeze will then respect those fields and focus remediation on the portal-local sprawl.
If you have a Data Hub subscription, Breeze can pull directly from property insights in the Data Quality Command Centre — fill rates, usage across workflows and reports, duplicates, and formatting issues. Add this line to the Context: “Reference property insights from the Data Quality Command Centre for fill rates, usage, and duplicate property counts.” The output will be noticeably sharper.
If you want to run this quarterly, save the output and re-run the same prompt 90 days later, adding: “Compare against the output from [DATE] and report on which actions were completed, which properties regressed back into sprawl, and which new overlaps have emerged.” That gives you a rolling property governance dashboard in prompt form — and a very easy progress update for leadership.
If you are preparing for a Breeze agent deployment, add this to the Context: “We are planning to deploy [Prospecting Agent / Customer Agent / custom Breeze Studio agent]. Weight the rationalisation plan towards cleaning up the properties those agents will read.” Breeze will then prioritise the firmographic, lifecycle, and activity fields the agents depend on, rather than treating all properties as equal priority.
Beyond the prompt:
The Rationalisation Plan is the strategy layer. Implementation follows a clear path inside HubSpot.
Start with the ARCHIVE_ naming convention. Before you retire anything, rename the property with an “ARCHIVE_” prefix and the date, then hide it from record pages, form editors, and list filters. The data is preserved, nothing downstream breaks immediately, and you have a 90-day grace period to catch anything that turns out to be load-bearing.
Then tackle overlaps. For each consolidation, build a data-sync workflow that copies values from the retiring field to the surviving field before archiving the original. Run it, verify the values, then archive. The worst thing you can do is retire a property and discover the “surviving” field was actually the one with the worse data.
Next, fix field types and put validation at the point of entry. Convert free-text industry fields to dropdowns with a controlled value list. Add required fields on forms where segmentation depends on them. Enforce format rules on phone numbers and URLs. This is what stops the sprawl from re-accumulating the day after you finish cleaning it up.
Then write down the governance model. A single-page SOP is enough: who can create properties, what information has to be captured in the request (purpose, owner, object, field type, allowed values, downstream use), what the naming convention is, and when the quarterly review happens. Restrict property creation to the roles named in it.
And if you are heading towards Breeze agent deployment — Prospecting Agent, Customer Agent, or something custom in Breeze Studio — this work is not optional preamble. It is the prerequisite. An agent reasoning over a coherent property model is a genuine competitive advantage. An agent reasoning over 180 overlapping custom properties with no naming convention is a very expensive way to be confidently wrong.
So go and rationalise your properties — your future self, your reports, and your AI agents will all thank you for it.
