--- title: "Bad HubSpot Property Design Will Ruin Your Automations" description: "Bad HubSpot property design can break your automations. Learn how to structure properties properly to improve data quality and workflows." image: https://www.mo.agency/hubfs/MO%20-%20Blogs%202026%20-%20How%20Bad%20HubSpot%20Property%20Design%20Can%20Ruin%20Your%20Automations%20-%20V2.png canonical: https://www.mo.agency/blog/2026-guide-to-hubspot-property-design-building-better-automations-mo-agency url: https://ai.mo.agency/blog/2026-guide-to-hubspot-property-design-building-better-automations-mo-agency.md last_converted: 2026-04-14T09:33:36.683Z --- [HubSpot](https://www.mo.agency/blog/topic/hubspot) # Bad HubSpot Property Design Will Ruin Your Automations Apr 14, 2026 · MO Agency Strategy Team ![](https://www.mo.agency/hs-fs/hubfs/MO%20-%20Blogs%202026%20-%20How%20Bad%20HubSpot%20Property%20Design%20Can%20Ruin%20Your%20Automations%20-%20V2.png?width=1200&height=600&name=MO%20-%20Blogs%202026%20-%20How%20Bad%20HubSpot%20Property%20Design%20Can%20Ruin%20Your%20Automations%20-%20V2.png) Share ## Bad HubSpot Property Design Will Ruin Your Automations Most HubSpot automations don’t break because you built a “bad workflow”. They break because the data underneath it is… dodgy. Not always wrong, just unreliable enough that you can’t trust it. And if you can’t trust the data, your automation is basically guessing. And the quickest way to create that kind of mess in HubSpot is sloppy property design. Not “sloppy” like someone did something insane. Sloppy like: you needed to ship something, everyone was busy, nobody wanted to start a whole “data governance initiative”, and you told yourself you’d clean it up later. You won’t clean it up later. It’ll just grow. ### A quick real example (because this is exactly how it happens) This week I was dealing with a property called Confirmed Countries. It’s a multi-select. Simple enough: tick the countries that are confirmed. The business then wanted a number that says how many were selected, so they could report on it and trigger a few bits of automation. Sounds tiny, right? Except HubSpot doesn’t just give you “count of selected values” in a workflow. So suddenly you’re writing a custom coded action just to count the selections and push the number into another property like Number of Confirmed Countries. And then you hit the next headache: making sure the output actually writes to the record properly. That’s the whole problem in one story. The property wasn’t “wrong”. It just quietly forced complexity downstream. ## It Starts Small (Then It Gets Out of Hand) You add one property to get something done quickly. A dropdown. A checkbox. You name it something vague like “Status” because you’re in a rush. Then someone else adds another property because they didn’t know yours existed (or they couldn’t find it because it’s buried in a group called “Misc” or just the default “Information” group). Then a third one gets created because the first two are “not quite right”. Then an integration starts writing to one of them. Then Sales starts editing it manually because the integration is “wrong”. Now you’ve got three properties doing the same job, none of them are consistent, and your workflows are trying to run a business process off vibes. And that’s when automations start doing embarrassing things. Enrolling the wrong people. Skipping the right ones. Creating tasks at weird hours. Re-enrolling people who are already customers. Making you look like you don’t know what you’re doing (even when you do). Then someone says: “HubSpot is being weird.” No. Your properties are being weird. ![](https://www.mo.agency/hs-fs/hubfs/undefined-Mar-23-2026-08-12-21-3622-PM.png?width=369&height=471&name=undefined-Mar-23-2026-08-12-21-3622-PM.png) ## Workflows Don’t Fix Data Problems, They Just Amplify Them A workflow is just a set of rules reacting to a value. That’s it. So if the value is unclear, inconsistent, or being overwritten from multiple places, the automation looks “random” even when it’s following the rules perfectly. This is why you can build something that works beautifully in testing… and then the portal goes live and two weeks later it’s chaos. Real users don’t behave like test records. They do whatever gets them to the next step fastest. ## The Free Text Trap (It Always Ends Badly) Free text fields are a quiet killer when you use them for anything operational. Someone makes a property called “Industry” and sets it as a single-line text field. In their head: “People will type ‘Financial Services’ and we’ll segment later.” They won’t. You’ll get: - finance - Finance - financial service - Financial Services - fin services - FS - banking - bank - and yes, occasionally “idk” ![](https://www.mo.agency/hs-fs/hubfs/undefined-Mar-23-2026-08-12-21-6334-PM.png?width=584&height=278&name=undefined-Mar-23-2026-08-12-21-6334-PM.png) Now try build automation around that. Routing? Good luck. Reporting? Also good luck. You end up writing workflows that do detective work: if it contains “fin” OR “bank” OR “financial”… and your automation logic is doing cleanup work that should never have existed. Free text is fine for notes. It’s not fine for logic. ## Dropdowns Can Still Be a Mess (If You Let Them) People love saying “just make it a dropdown” as if that magically fixes data quality. It doesn’t, if the dropdown options are a bin. You open a “Lead Status” dropdown and it’s got stuff like: “Demo booked”, “Demo scheduled”, “Spoke to them”, “Left voicemail”, “Follow-up sent”, “Not interested”, “Qualified”, “Hot”, “Warm”, “Waiting for response”… half of it is actions, half of it is vibes, and some of it overlaps. Nobody is going to stop and think, “hmm, which one best matches the defined meaning of this option?” They’re going to click whatever looks closest and move on. So the data looks structured, but it behaves like free text because everyone interprets it differently. ![](https://www.mo.agency/hs-fs/hubfs/undefined-Mar-23-2026-08-12-21-9790-PM.png?width=517&height=455&name=undefined-Mar-23-2026-08-12-21-9790-PM.png) ## Multi-Select: Feels Smart, Usually Isn’t Multi-select makes people feel like they’re being flexible. It also creates chaos fast. The second you allow multiple values on something that’s supposed to be a single truth (stage, status, decision, whatever), you’ve basically said “this property can contradict itself”. Then you’re building workflow logic like: - if contains X - but not Y - unless it also contains Z - and only if A is known That’s not automation. That’s you trying to outsmart your own bad property design. Use multi-select when multiple values genuinely need to be true at the same time. Tags. Interests. Product lines. Fine. But if you’re using multi-select to represent a stage or a decision, you’re building yourself a problem. ## No Ownership Means Nobody Trusts It Another one that sneaks up on you: nobody owns the property. Marketing thinks it’s theirs. Sales edits it anyway. Ops builds workflows off it. The integration overwrites it. And everyone complains that it’s “not accurate”. Of course it’s not accurate. It’s being touched by too many hands and too many systems, and nobody has decided what the rules are. Once a property loses trust, people stop using it properly. Then your workflows become less reliable. Then people bypass the workflows. Then you’re doing manual reporting again. ## The Fix: Treat Property Design Like Automation Design You don’t need a big governance project. You do need to stop treating properties like admin clutter and start treating them like automation infrastructure. Before you automate anything important, answer these: - What does this property mean in one sentence? - Who is allowed to set it? - Where should it be set: form, workflow, integration, manual? - If more than one thing can write to it, which one wins? - Should it be one value or multiple? And one more thing that catches people out: make sure the property definition matches the business rule. I had this exact conversation recently with a time-based calculation. Someone wanted a property that meant “two months after X”. Then we realised the actual rule was 10 weeks. Those aren’t the same thing. Months vary. Weeks don’t. If you build automation off “2 months” you’re guaranteed edge cases and weird behaviour that looks like HubSpot being broken. Sometimes it’s not even the workflow. It’s the fact you defined the rule vaguely in the property. ## The Blunt Truth Messy properties make you feel like you’re [constantly fixing HubSpot](https://www.mo.agency/solutions/hubspot/rescue-rehab), when in reality what you are really doing is cleaning up after decisions that were made too quickly. Workflows don’t create order. They amplify whatever order (or disorder) already exists in your data. So if your automations are misbehaving, don’t start inside the workflow tool. Start with your properties. [Scroll to top](#top-banner)