u/Agile-Pension4568

Revenue Agent starts consuming credits on 16 September. 500 credits per invoice, charged when it begins collection outreach. Knowledge Base Agent goes on the meter the same day at $2 per new article.

I'm testing Revenue Agent right now, which is why I went looking. We invoice out of Morning, an Israeli platform, and the native invoice sync covers Stripe, Xero and QuickBooks only. So we put our own dev hours into building the connection, back when none of this was priced.

A few things that aren't obvious from the update text:

Enrolment is per company, not per invoice. Enrol an account and the agent picks up every open invoice on it, not just the overdue one. It also pauses your static invoice reminders while it's active, which makes sense, but matters if you have a workflow doing that today.

The 500 credits fire when outreach starts, not when the invoice is issued. So the number to model is invoices you actually end up chasing, not invoices you send. For us that's well under half.

Stripe and Xero sync was added this month. Before that it was QuickBooks or custom.

Two things I can't resolve.

Whether 500 credits is once per invoice or once per outreach cycle. If the plan regenerates because the invoice changed, or the agent re-engages after a gap, does that bill again? Nothing I've read says either way, and the difference is large if you're carrying a lot of slow payers.

And the credit rate. KB Agent is the only one of the two priced in dollars, at $2 for 200 credits. If that rate holds across agents then 500 credits is roughly $5 an invoice. I've been working on that assumption without finding anything that confirms credits price uniformly per agent rather than per feature.

Separately, Buyer Intent shipped a portal level monthly credit cap this month, under Usage and Limits. Neither of the two agents going on the meter has an equivalent ceiling that I can find. Metering usually ships ahead of the controls so I'm not reading anything into it, but if someone has found a cap for Revenue Agent I'd like to know where it lives.

(Partner, so weigh the "a published price is fine actually" part accordingly. I'd still rather have a number than find out at renewal.)

Has anyone run Revenue Agent long enough to see how the credits land on a repeat chase?

HubSpot's batch testing for Customer Agent is in public beta, and the part worth knowing is what happens after the run rather than the run itself.

Setup, briefly: we wrote the agent guidelines from the client's actual requirements, then generated the test set from those guidelines rather than from imagination, so every question was checking something we had already committed the agent to doing. Mix of ordinary visitor questions and deliberately awkward ones. Certification questions with nothing behind them in the knowledge base. Competitor comparisons. A journalist asking for a quote. One question typed the way a bored person actually types.

https://preview.redd.it/nf0jmf4z9omh1.png?width=1559&format=png&auto=webp&s=a4d71de16d8e9e01861a364366d1f3f3a164285b

All of them came back with an answer. Not a single "I don't have that information," including the ones where nothing on the site or in the knowledge base could have supported an answer. That is not a batch testing problem, it is just what default confidence looks like when you finally see 40 answers next to each other instead of one at a time.

Marking a case Looks bad opens the remediation in place. You can push it into a short answer or back into the guidelines without leaving the screen, and Breeze Assistant reads the case and will argue a recommendation with you. More useful than it sounds, because the sorting decision is the actual work.

Where I landed:

Vague or wrong content on a question that has one correct answer is a knowledge source problem. Short answer is fine there.

Right content, wrong behavior is a guidelines problem. Ours was the agent answering acceptably and then immediately asking for a business email instead of being useful first. It turned up on questions with nothing in common, which is the only reason I read it as behavior rather than a bad answer.

Fix that one with short answers and you will be writing a short answer per phrasing indefinitely, watching every case go green while the agent carries on doing it.

The bit I can't account for. The email-first behavior persisted in cases where the guidelines said to answer before asking for contact details. I don't know whether there is a lead capture setting that outranks guidelines, whether my guideline wording was too weak, or whether I am misreading the precedence entirely. Has anyone actually pinned down what wins when a channel-level lead capture default and a guideline disagree?

Separately, Test in a thread carries a batch question into the live test screen so you can continue it as a conversation, but the batch score itself is still a single turn. Anyone found a way to batch anything multi-turn, or is that manual for now?

Every portal I audit gets a health dashboard early on, and the report I check first is contacts with no associated company. Then deals with no associated contact, which is usually worse.

Nobody has ever looked at those numbers before I show them, and they're usually higher than the client expects.

It goes unnoticed because it doesn't look like an association problem from the outside. What you see is a copy property value action that silently does nothing, since there's no associated record to read from. Sometimes it's a list that should have caught someone. More often it's reporting that's off by an amount nobody can quantify well enough to escalate.

The existing fix is the Create associations workflow action, matching on a property value present on both records. It's limited to a handful of property types, the values have to exist on both sides, and the match is case-sensitive and exact. A contact with "hubspot" in Company name won't match a company called "HubSpot."

So it works on portals clean enough not to need it. The ones with real association gaps tend to be the ones where the values don't agree in the first place.

There's a new action in private beta called Copy associations that works differently. Instead of matching on a value, it bridges two records through a third one they're both already associated with. Company is associated to a deal and to a contact, the deal and the contact aren't associated to each other, workflow connects them.

The part I'd want to understand before running it on anything real is the fan-out. It creates associations for all associated records, not one pair. A deal with three contacts and two companies produces six new associations in one pass.

There's also no undo. Associations created without a label can't be removed by workflow afterwards, because the Remove association labels action only works on labelled ones. An unlabelled bulk run leaves you deleting records or fixing it by hand.

I haven't tested it, it's not in my portals yet. If anyone here is in the beta, does the fan-out behave the way the docs describe, and is there any dry-run or preview before it writes?

HubSpot is preserving the primary record's ID through merges again. Live now, all hubs and tiers, applied automatically with nothing to switch on. If you store HubSpot record IDs in a warehouse, a billing system, or any product integration, this is the one worth reading about this month.

Tested it this week. Primary was 227016195210. After the merge the surviving record is still 227016195210, and Merged Contact IDs reads 227087463431, 227016195210. Under the behavior we've had since January 2025 that surviving ID would have been a third number belonging to neither original. Screenshot attached.

https://preview.redd.it/1y6nk8v15alh1.png?width=798&format=png&auto=webp&s=d3df2808ffc256adcb88f265ad2257576e5f3b4e

Why it matters, for anyone who wasn't bitten by it: contacts and companies used to keep the primary ID on merge. That changed in January 2025 to standardize with how deals already behaved. Old IDs still resolved inside HubSpot so the UI looked fine, but anything holding that ID externally was pointing at a record that had stopped existing.

Merging stayed possible. It just stopped being cheap. You had to know which systems stored the ID and what they'd do when it changed before you touched anything, and since a native merge unenrolled both records from every workflow they were in, you were auditing automation in the same sitting. Deduplication turned into a scoped project, and scoped projects get scheduled for a quarter that never quite arrives.

So the practical upside is that record ID is a dependable external key again, and cleanup goes back to being routine rather than something you plan around. Not retroactive though, so historical merges keep the old behavior and reconciliation logic now has two eras in it.

One thing I'd like confirmed by someone who has tested it. Native merges have always unenrolled both records from every workflow they were in. There was a separate 18 August update about workflow enrollments preserving the main object record when merging, but the release note wording is vague enough that I don't want to state what it does now. Has anyone watched a merged record stay enrolled in an active workflow since that shipped?

The HubSpot Sales extension sidebar is configurable now, in beta. You add and remove cards, choose which properties show on each, reorder them, and set up the Email and Prospecting views separately, per object. Settings > General > Email > Extension settings > Customize Sales Extension Views.

I opted in yesterday. Two things before you do.

Opting in wipes your existing sidebar config. You rebuild whatever you had, including the About this contact property list. HubSpot says the full migration will carry your current setup over automatically when it lands, so waiting is a real option rather than a consolation prize.

Configuration is admin only for now.

Two new cards came with it. Lead stage tracker shows lead owner, lead type, stage and pipeline on the contact record, which is the part I actually wanted. Prospecting agent shows enrollment status and a Review outreach button.

The part I can't account for is that Prospecting agent card. Mine says the enrollment finished and 0 emails sent. The Activity tab on the same contact lists emails the agent drafted and I approved. I have not sent anything to this contact manually, so those are agent emails and the card is counting none of them.

One thing I can't rule out: the card is showing a specific enrollment run, mine is dated 11 Aug and has a Re-enroll button, and the approved emails may have gone out under an earlier run. I have not gone back through the send dates yet.

Anyone else opted into this beta? Mainly wondering whether that counter reads 0 for you too, and whether the card is scoped per enrollment run or all time.

https://preview.redd.it/ag3sas3qiakh1.png?width=890&format=png&auto=webp&s=36ca1f1365bb3ca968d787347eaa0b7ef70f5a5a

HubSpot shipped a Data Model Health Check last month, under Data Management > Data Model > Health. It scans properties, objects, associations, pipelines and lifecycle stages and returns a list with suggested actions. I ran it on a client portal this morning. Posting the numbers because I haven't seen anyone write up what it actually returns.

Portal totals: 1 object issue, 132 property issues, 31 association issues, 19 pipeline or lifecycle issues, across 10 objects.

Top objects by issue count: Contacts 70 (all property), Companies 37 (all property), Deals 31 (18 property, 9 association, 4 pipeline), Contracts 17 (all association), Tickets 11.

The property filters are low fill rate, low fill rate with high usage, low fill rate with critical usage, duplicate property label, and high fill rate with low usage.

That last filter is the one I'd start with. A property your team fills in reliably that nothing downstream reads. It never looks like a problem because the fill rate is fine.

A decent chunk of the output is scaffolding, though. The Contracts object came back with 17 association issues and every one is a default association that ships with the object. Contract-to-Quote, Contract-to-Company, Contract-to-Credit memo, Contract-to-Subscription, all sitting at 0 records associated. The portal doesn't use Contracts. Nothing is misconfigured. That's 17 of the 31 association issues in the entire portal.

Same pattern on Deals. Four pipeline issues, all "stage with no records," all on one pipeline that got built and never adopted. Correct finding, but the table lists one row per flagged stage, so a single dead pipeline shows up as four issues in the summary count.

The one I can't explain: on Contacts, a batch of properties came back tagged "low fill rate with high usage" showing a fill rate of 0% and a "Used In" count between 1 and 4. Zero percent fill, referenced in up to four places. Either something is reading a property that has never once been populated, which is a live broken dependency and considerably more interesting than a cleanup task, or "Used In" is counting something other than active assets. I haven't opened all of them to check.

Access is Super Admin or Partner Admin only. It runs automatically the first time you open the tab, takes a couple of minutes, and there's a re-run button after you fix things.

Anyone worked out what "Used In" actually counts? And has anyone found a way to suppress the default-association noise, or do you just learn to skip past it every run?

https://preview.redd.it/cgchiyeokbhh1.png?width=3884&format=png&auto=webp&s=bf79512e208dfdfb2b9b12c5669e1a484bbfabae

Three hours, twenty smart properties, built the regular way, hand-written prompts pulling from company activity to enrich records automatically. Tools used, current stack, that kind of thing.

Checked each one as it was built, not after. Opened it up, looked at what source the answer actually came from, not just whether a value populated.

Good thing I did. Most of the problems were in properties sourced from transcripts and activities specifically. A rep name-drops a competitor's stack on a call, or an outbound email uses another customer as a proof point, and the model reads that mention and quietly assigns it to the company being enriched. Association isn't attribution. The activity being on the record doesn't mean the content is about that company.

Tried to fix the prompts myself first. Didn't hold. Tried it with Claude too. Same result.

What actually worked was going through Breeze's assistant one prompt at a time. Not one fix, twenty separate passes, since what each property needed to capture wasn't the same. Same underlying logic every time, different ask. Took a while, but got every single one to only pull from the right sources.

None of this was live. Nothing populated on a real record before it was caught, since it was all still in testing.

Worth saying plainly: an empty field tells you what you don't know. A wrong one tells you the wrong thing with total confidence, which is worse for anyone downstream trusting the field.

If you're building smart properties on activity-based sources, transcripts especially, check the source before you check the output. I'll drop the prompt structure that ended up working in the comments if anyone wants it.

HubSpot partner here, so factor that in.

For anyone who hasn't seen it yet: Teamwork is HubSpot's AI-first workspace, built inside HubSpot, where your team and AI agents run projects, tasks, and documents connected to your actual CRM records. It's currently a private beta, Core Seat required, and it works from templates (client onboarding, deal desk, webinar planning, editorial pipeline) or you describe what you want built and it generates the structure.

Posted a week ago when Teamwork went into private beta. Been running it for our own internal ops for about a week now, so sharing the actual experience rather than the change log version.

Setup was one call plus describing what we wanted in plain language. No manual table-building, no settings menu.

The part that surprised me is how changes work afterward. Same mechanism as setup: you open a conversation with the agent, same pattern as Breeze elsewhere in HubSpot, and ask for what you want changed. New automation, different task view, another agent watching for one specific thing. No digging through config screens to get there.

In practice, right now it's handling: task creation from calls, Slack messages, and emails, plus a daily task brief every morning pulled from what's open across the workspace.

Caveats, since a week isn't long: this is internal ops only so far, not client-facing work yet, and it's still private beta, so some of this may change before GA. Also worth saying, it's stepping onto Asana/Monday's territory for the project-management layer specifically. The CRM connection is the part that's actually new, not the task board itself.

Anyone else in the beta pushed this further, especially into anything client-facing, or is everyone still in the "internal ops sandbox" phase like us?

Restore CRM Changes lets you pick Integration as the source now. So when an integration writes bad data you can roll back just that app's changes instead of a broad restore that reverts everything else from the same window too. Enterprise, public beta.

Up to now if a sync or a private app messed up a bunch of records, you either did the source-blind restore (and reverted unrelated stuff along with it) or you exported the property history and re-imported the old values, which is about as tedious as it sounds. The per-record Undo doesn't work on connected app or API changes at all, so that was never on the table for integration writes anyway.

The source list includes MCP connectors now too, Claude's in there. Probably the part I'd watch, since a lot of people are starting to let agents write straight to the CRM and an agent doing the wrong thing quickly is just the import problem again with extra steps. Being able to undo one source without touching the rest helps.

Say a Salesforce sync misfires and overwrites lifecycle stage on a few thousand contacts. You can now pull back just that sync's writes from the window.

One thing I can't tell from the release notes: it's described as property changes, but the restore tool also has a separate Created records type. Anyone in the beta know if the Integration filter covers both, or just modified properties? Wondering what happens with an integration that created and updated records in the same run.

Revenue Hub launched and half the comments I'm seeing are some version of "oh, Commerce Hub with a new name." I get why, the marketing doesn't help, but that take misses what actually changed.

The actual change isn't one new feature, it's that quoting, contracts, billing, payments and renewals run off the same chain inside the CRM now, instead of four tools you stitch together by hand. If you've run recurring revenue in HubSpot you know the old setup: quote in one place, contract in a folder somewhere, finance rebuilding the invoice by hand, and by renewal nobody's totally sure what the customer is even paying for.

The thing that makes the chain actually hold together is the Contracts object. It's a proper CRM object now, like contacts or deals. Accept a quote and a contract gets created automatically with the term dates, MRR/ARR, line items, all of it. Someone adds seats mid-term, you spin a change quote off the contract and it handles the proration. Renewals pull the current products off the existing contract so you're not rebuilding anything from scratch. Basically the glue that was always missing.

Worth saying though, none of this rescues you from setup. The contract just inherits whatever's in the quote, so if your product library and pricing rules are a mess, congrats, now the mess moves downstream automatically. CPQ's only as good as what's under it.

Also, for anyone not in the US, before you get excited or annoyed: HubSpot Payments is US/UK/Canada only. Everywhere Stripe operates you collect through Stripe, so payments aren't off the table outside those three. If you're billing into the EU, the part worth scoping is e-invoicing. The card flow is the easy bit.

Anyway. Anyone actually moved quoting and contracts into HubSpot yet, or is your billing stack too embedded to bother?

HubSpot partner here, so factor that in.

Pipeline rules are coming to contact and company lifecycle stages. In public beta now, supposedly going GA around 29 June. Basically the same rules deals and tickets already had, finally on contacts and companies.

Three of them, under Settings > Objects > Contacts (or Companies) > Lifecycle stages > Pipeline Rules:

• Limit contact creation to specific stages (you can also set a default creation stage)
• Restrict contacts from skipping stages
• Restrict contacts from moving backwards

The creation limit is the one I'd switch on first. Right now nothing stops someone importing a list of event badge scans straight in as MQL, and then your funnel looks great for a week while your conversion rates turn to garbage. Skipping and backwards matter too, but the only real protection lifecycle stage ever had was that automation won't set it backwards, and everyone gets around that by clearing the value first anyway, so it never did much.

Caveat that's going to come up in the comments before I even finish typing this: per the beta UI, Super Admins, anyone with permission to edit property settings, and pipeline automations can bypass all of it. So it's not a hard lock. It stops normal users doing normal-user things. If your mess is being made by an admin or a workflow, this isn't your fix.

Anyone in the beta already turned the creation limit on? Wondering whether it plays nicely with imports and integrations or just throws errors everywhere.