The Problem
I have a HubSpot workflow with custom code that should count custom object records with a specific property value associated to a company. The workflow runs successfully but returns 0 when I manually verified there should be 2 matching records.
What I’m Doing
- Using V3 associations API to get custom object IDs linked to a company
- Using V3 batch read to get properties from those records
- Counting records where urgency property equals “High”
- Expected: 2, Getting: 0
Already Verified 
- Custom object ID and API name are correct (copied from HubSpot settings)
- Property internal name urgency is exact match
- Property values are exactly “High” (case-sensitive confirmed)
- API permissions are correct
- Company has 2 associated records with urgency=“High” (manually verified in UI)
- Workflow executes without errors
- Association calls and batch reads appear successful in logs
The Question
Has anyone hit this issue where custom object property comparisons fail even when everything looks correct?
What could cause record.properties.urgency === “High” to not match when the data definitely exists and the API calls succeed?
Any insights on HubSpot custom object quirks or common gotchas would be super helpful!
The item that pops in my mind is that “High” might be the label you see in HubSpot and “high” might be the value (internal name) that you need to be checking against. If this field is a choice type property (eg, dropdown), the actual value that gets stored might be different from the label. You would need to see what the internal name is.
For example, this is how one of my fields show up
If you’re having issues with the comparison, you can either output the value of the field into the log and see what it shows.
console.log("Urgency value", record.properties.urgency);
And then check the custom code action logs for it.
Another option is to run the API request in Postman and check what value is being returned for the field.
Likewise, if you have access to the GraphQL explorer in HubSpot, you can build a query and see what gets returned.
Hey @RocioLin ,
The mismatch usually comes from how HubSpot stores option values versus what you see in the UI. The label might say “High,” but the API is often returning "“high” or “opt_high”. If the field is multi-select, you’ll also see a semicolon-separated string like “High;Medium”, which won’t match a strict equality check. Small things like whitespace or case differences can trip it too.
The quickest way to confirm is to fetch the property definition with /crm/v3/properties/{objectType}/{propertyName} and look at the option’s value field. That’s the string HubSpot is actually storing. Then log the raw batch-read response and see what comes back under record.properties.urgency. If it’s multi-select, split it, normalize the strings, and compare against those values instead of the UI label.
Most times, the code is checking for the display label when the API is returning the stored value. Once you line those up, your count will match what you see in the portal.
I hope this helps clarify your query. If it answers your question, please mark it as the accepted solution and give it an upvote to help the community.
