Show recap — Thursday, August 6, 2026

Another Orange Morning Recap: August 6, 2026

Thursday started with a small technical indignity. Casey's browser freaked out during the theme song, so she had to leave and rejoin, and by the time Chris got to saying good morning she was not on stage yet. Chris then admitted he had not been paying attention to the song at all, which raised the obvious question of how much value a two minute theme song is really delivering. Trisha Merriam was in the Friend seat and got to watch all of this happen before a single update was opened.

Here is what we got into: a private beta that finally converts a text property into a dropdown without destroying the data in it, merge rules that let you decide which duplicate record survives, brand-specific company names on buyer-facing emails, a long argument about whether team email signatures should exist, the Settings API opening up seat management, and then the back half of the show spent building a lookup property live with Breeze instead of talking about one.

The One That Would Have Saved Somebody Time Yesterday

Convert A Text Property To A Dropdown Property

If you join this private beta, you can convert single or multi line text properties into a dropdown select property while preserving the data already sitting in them. Data models have to evolve, and until now, if records already had values in a free text field, you could not turn that field into a standardized dropdown.

The old path was madness and everyone who has done it knows it. You built a proxy field, moved all the data across, emptied the original, then re-imported from the temporary field. Four steps and a held breath. Most people looked at that, decided it was not worth it, and left the field as text forever, which is how you end up with a portal full of fields that were supposed to be cleaned up eventually.

The more interesting part is not the feature, it is where the AI actually shows up. Everybody looks at Breeze and agents when they think about AI in HubSpot. The quiet version lives in the backend: reading a column, inferring that it looks like a dropdown and probably carries these options, and transforming the values on the way across. That used to be a real engineering lift, which is exactly why this never existed before.

The timing was cruel for at least one person on the call, who had done this the hard way the previous day and was, by their own description, a little bitter about it.

For more details, see converting a text property to a dropdown on the updates feed.

Deciding Which Duplicate Survives

Merge Rules And Winning Record Rules

Merge rules let you programmatically decide which record in a duplicate group becomes the primary, or winning, record. Soon they will also support property overrides, so a value from a secondary record can survive the merge even when that record does not.

Dedupe tools have done this for years. Insycle, Dedupely and Qualify all let you write a real rule: if the record is associated with a deal, that one survives. If it is the one with the Salesforce account tied to it, that one survives. HubSpot has not had that. The criteria it did offer, created first or most recent engagement, are not what anybody actually merges on.

The property override piece is the part worth waiting for. Choosing a winning record is only half the problem. The other half is keeping the one good field that lives on the record you are about to lose.

Trisha brought a point in from a conversation before the show that stuck for the rest of the segment. The language here is doing something odd. A record is only winning until you need a value from the other one to override it, and at that moment the label stops describing what is actually happening. It is conditional, and conditional things are hard to name. So be careful how you train your teams on the word winning, and if you are going to use it, define it clearly everywhere it appears.

For more details, see merge rules and winning record rules on the updates feed.

The Brands Gap Nobody Talks About

Brand-Specific Company Name In Buyer Emails

Starting August 10, buyer-facing emails will display the company name tied to the brand associated with the triggering transaction, rather than defaulting to the portal-level company name. Subscription confirmations, payment receipts and related notifications will match the brand the buyer actually bought from.

If you sell under multiple brands, your buyers have been getting receipts with the wrong name on them. From their side that reads as a mismatch at exactly the moment you want them feeling confident about the purchase.

The real story here is parity. Brands landed for marketing email a while ago and everybody did that work. Transactional and commerce email were left behind, so you either accepted the wrong name or built a workaround to get around it. These are the small things that sit in front of really good functionality and quietly stop people from using it.

One thing worth knowing: when no brand is associated with a transaction, the emails fall back to the portal-level company name. So this rewards actually having the brand association set, not just configured.

For more details, see brand-specific company names in buyer emails on the updates feed.

Should Team Email Signatures Exist At All

Team email signatures are now more visible, more personal and more flexible across the CRM, inbox and help desk. You can preview a signature before sending, personalize it with details like a profile picture and meeting links, and switch between your personal and your team signature.

This one turned into a strategy conversation rather than a feature conversation. The update describes team signatures as having lacked the personal touch reps wanted, but you usually reach for a team-based email precisely because you do not want to name a person. It is a shared inbox, and the justification is always the same: what if this person is out today, somebody else from support needs to pick it up.

The counter-argument on air was that we have the technology for that now. Coverage does not require anonymity. And the worst version of this is copying a shared address on everything just so everybody gets it, which leaves you with two versions of the same email and no clear owner.

So yes, being able to switch between the two is better than not being able to. But the moment you introduce a team signature you have made a decision about whether you are interacting with people as humans, and that decision deserves more thought than it usually gets.

For more details, see team email signature improvements on the updates feed.

The Most Infuriating Update In HubSpot History

Somewhere in the middle of the show the question came up: what is the most infuriating update you have ever seen, from the perspective of nobody should be doing this?

Chris did not need time to think about it. September, first day of INBOUND 2024, when the Leads object was announced. He could remember the day. We survived it, and he says he will let it go, though the speed of the answer suggested otherwise.

Seats, And Where This Is All Going

Settings API And User Provisioning

The Settings API now enables fuller seat management, including viewing seat limits and availability, assigning seats at user creation, and updating seats for existing users. User setup and seat management were incomplete by API before this, so you could do part of it programmatically, hit a wall, and finish by hand.

The near-term use is easy to picture. A new employee starts, and you work with AI on what permissions and seats that person actually needs, and it provisions them. The honest counterweight is that AI gets things wrong, and the failure mode here is people holding seats they do not need with nobody noticing.

The longer arc is the part worth sitting with. As seat management gets this flexible and opens up via API, the case for a separate seat per human starts to erode. Between this, reporting coming to Starter, and the general direction of the platform, an agentic customer platform ends up priced on usage at some point. If you are running a fairly industrial seat model today, that is worth thinking about now rather than when the pricing actually moves.

The Price Books public API got a nod in the same breath, as part of a run of API releases that is now close to daily.

For more details, see the Settings API user provisioning update on the updates feed.

We Stopped Talking About Lookup Properties And Built One

Associations As Lookup Properties

Lookup properties surface a labeled association as a property value, capturing not just that two records are related but the nature of that relationship. They are currently available for one-to-one custom association labels, and they will be available everywhere properties are surfaced today, on record pages, forms and elsewhere.

This update keeps coming back on the show, and there is something useful in that. We have now talked about lookup properties with several different friends this week, each from a different angle. Trisha picked it as her update, and when asked whether it matched what she had been hoping for, she said she still did not know, that it was not clear to her what it actually does. She had read it a third time and told herself a different story about it than the time before.

So rather than read it a fourth time, we built one.

Breeze was asked where this new beta should be used in the portal. It came back saying the beta is a good fit and the best place to use it is anywhere you need one clearly defined primary relationship to be easy for reps to set, see, filter, report on and automate. Lookup properties are useful for turning an important relationship into something that behaves like a normal field, instead of forcing the team to manage it only through the associations panel.

That is also where the friction is. Lookup properties want one most important linked record per object, and it is rarely one most important record. It also does not get you out of the business of managing association labels, which is the thing a lot of people were hoping to escape.

The build itself was the interesting part. Breeze proposed a set of candidate labels, then moved to formatting a proposed labeled version for review before making changes. It stopped and asked for confirmation because the change touches the data model, which is the right instinct. Then it created the association label, complete with a description, and handed back the next step: build the actual lookup property on the object using that relationship.

Two things came out of watching it happen. The first is that Breeze is now moving forward with work rather than asking permission at every turn, and the room was mostly fine with that, on the grounds that it is not publishing anything unresolvable and edits are cheap. The second is that data modeling is a muscle the ecosystem largely does not have, and this is exactly the kind of task worth handing to AI for that reason.

The ending was honest. The result was not what either of them pictured. Building the property asks you to choose an association label up front, which is unusual, and what renders is a list of account records rather than the clean single field the description had suggested. It still points somewhere good. Being able to put that relationship right next to the other properties a team already works with, instead of sending them to the associations sidebar, is going to help a lot of people. It is just not the thing anybody had imagined from reading it.

For more details, see associations as lookup properties on the updates feed.

A Note On Mental Burpees

While waiting on Breeze, the conversation turned to something that has nothing to do with HubSpot and everything to do with working this way. You send a prompt, then you go do something else, then you have to come back and pick the thread up again. The context switching is the expensive part, not the waiting.

Mental burpees was the phrase, and it is a good one. You can do burpees for a while. You cannot do them all day. The proposed solve was not less AI, it was better infrastructure around it, which loops back to the same thing the new HubSpot homepage is reaching for: something that tells you what is next so you do not have to hold it all yourself.

The Sign-Off

A private beta that fixes a properly annoying data problem, merge rules that finally let you write the rule you always wanted, brands reaching commerce email, seats opening up to code, and a live build that did not go where anyone expected. That last one might be the most useful thing on the list, because reading an update a third time is not the same as pressing the button.

Full breakdowns of everything that shipped, along with our take on each, are on the HubSpot updates feed.

See everybody tomorrow.