Hey everyone! I'm starting to work more with our HubSpot portal, and I've seen how fast custom fields can get out of hand. We're already seeing duplicate field names for different objects and it's confusing for the dev team.
I'm looking for best practices on structuring these from the start. For example, should we use prefixes for different modules (like `contact_custom_`, `deal_custom_`)? What about grouping related fields? Our main use cases are tracking implementation project details and custom product interest flags.
I set up a test field group in Python to model it, but I'm not sure this logic translates:
```python
field_structure = {
"group_label": "Implementation_Project",
"fields": [
{"internal_name": "project_tech_stack", "type": "text"},
{"internal_name": "project_go_live_date", "type": "date"},
]
}
```
Any guides or lessons learned on keeping this scalable would be awesome! 😅
We just finished a cleanup project for a HubSpot portal at my current gig, a ~150 person SaaS company. I've been through this twice, and it's painful every time.
The mess you're describing is inevitable unless you enforce a rigid system from day one. Here's what I enforce now:
* **Strict Prefixing:** Use the object name as a prefix for *every* custom field, like `deal_implementation_tech_stack` or `contact_product_interest_flag`. This eliminates the duplicate name issue instantly. It's verbose, but it saves dev time.
* **Group Names as Function:** Name your field groups by their *business process*, not by department. "Implementation_Project" is good. "Marketing_Fields" is bad. This keeps fields for the same process together, even when multiple teams touch it.
* **Limit Text Fields:** HubSpot's text fields are a black hole for unstructured data. For things like tech stack, I use a single-line text field and enforce a comma-separated list convention, or I use a dropdown with predefined values if possible. It reduces reporting chaos later.
* **Document the Internal Name:** HubSpot shows the friendly label in the UI but uses the internal name in APIs and workflows. Maintain a simple spreadsheet mapping the internal names (e.g., `deal_project_go_live_date`) to their labels. Share it with anyone who touches the backend.
My pick is to adopt the prefix rule immediately and retroactively rename existing fields. It's a weekend of cleanup work but prevents months of confusion. Whether this works depends on two things: how many fields you already have, and if you have any external integrations already using the current internal names. Tell us those numbers.