Grandes mentes pensam igual

We’d like a customer-facing setting that allows admins to fully disable Conversational Context analysis, rather than only managing the related notifications. The KB confirms this cannot be turned off.  Right now, the available workaround is to disable the notification, but that does not solve the core issue for customers who want more control over whether this analysis happens at all.   This would help with: Transparency for customers who want a clearer understanding of how conversation data is being analyzed Granularity so teams can choose whether to keep notifications, analysis, or both Customer control for portals that do not want this functionality enabled by default Suggested improvements: Add an admin-level on/off setting for Conversational Context analysis Separate the controls for analysis and notifications Provide clearer in-app explanation of what the feature does and how the data is used This kind of control would reduce friction for customers and make the feature more flexible for different use cases. The current limitation is not about cost, but about the lack of a customer-facing setting to disable it. While the notification can be turned off today, the underlying analysis setting cannot currently be disabled.   ... Exibir mais

HubSpot currently does not provide a native property that reliably tracks the most recent operational source that modified a record (import, workflow, integration, web activity, API, manual edit, etc.). The existing properties only cover parts of the problem: Record Source and Record Source Detail only track how the record was created, not subsequent updates. Latest Traffic Source and its drill-downs only update when a new analytics session is created. CRM-only events (imports, workflows, integrations) do not trigger an update. Additionally, imports are sometimes classified as the session source and sometimes not, depending on the contact's prior analytics history, which makes the property inconsistent and unreliable for reporting or automation. Property history provides audit-level traceability but cannot be used for segmentation, lists, workflows, or reports. Use case: As a partner working with Enterprise customers, we need a native property that allows us to: Audit record changes and understand the most recent source of update; Segment and report based on the latest modification source (e.g. "all contacts last updated by an import in the last 24h"); Trigger automation when the last update comes from a specific source (import, integration, web activity, etc.). Current workaround (not scalable): The only viable path today — as explicitly confirmed by HubSpot Support in a recent ticket — is to build a custom property (e.g. "Last operational update source") and manually populate it from every process: import file mapping, "Edit record" actions in workflows, integration logic, API calls. This is fragile, requires ongoing maintenance, is prone to human error, and does not cover cases where the record is edited manually by a user. Request: A native, fully HubSpot-managed property — "Latest Record Update Source" (and related drill-downs) — that automatically updates on every record change regardless of source, with a standardized set of values (Import, Workflow, Integration, API, Manual edit, Web activity, etc.). ... Exibir mais

When dealing with large segments, checking the master checkbox at the top left of the table only selects the records on the current page (e.g., 25, 50, or 100 records).   To select the entire segment, HubSpot displays a small, blue text link "Select all # records". Because this text is small and embedded in a light blue banner, it's very easy to miss. This UI layout frequently leads to:   Accidental partial actions: Users thinking they've selected the whole segment, only to accidentally apply a bulk change, sequence enrollment, etc., to just the first 25, 50, or 100 people.   UI Frustration: Users spending unnecessary time hunting for how to select their entire segment.     Proposed Solutions:   Turn it into a button: Instead of a hyperlinked text string, make "Select all # records" a clear, high-contrast button within that action bar.   Increase visual contrast: Give the banner a more distinct background color or border when a user checks the master box, signaling that a secondary choice needs to be made.   A clear warning/pop-up: If a user clicks a major action (like "Enroll in sequence") while only a page-level selection is active on a multi-page segment, show a quick prompt asking: "Do you want to apply this to the 25 selected rows, or all records?".   This small UX improvement would save teams from major bulk-editing headaches and make segment management significantly more intuitive. ... Exibir mais

In Sequences and sales email templates/snippets, the Fallback value for a personalization token currently only supports static text (e.g., “there”). We often want a more intelligent fallback based on another property (e.g., “Preferred name, else First name, else there”), but that isn’t possible today. Problem: The fallback for a token like  {{ contact.firstname }}  can only be plain text. We can’t express logic like: If  Preferred name  exists → use that Else if  First name  exists → use that Else → use “there” This forces us to do more data‑engineering and workflows just to get reasonable fallbacks, rather than handling it at the content level. Proposed solution: Allow the fallback field for a token to reference: Another property (e.g.  contact.preferred_name  as fallback for  contact.firstname ), or A simple priority chain (e.g. “Preferred name OR First name OR static ‘there’”). This could be surfaced either via: A UI that lets us choose a “backup property,” or A simple expression/logic builder for token fallbacks. Why it matters: Produces more natural, human‑sounding emails without heavy data prep. Reduces risk of awkward greetings and salutation issues in sales outreach. Gives more flexibility for multi‑language and multi‑region setups where naming conventions differ. ... Exibir mais

Hi team, Currently, sorting is inconsistent across different sections: Overdue — chronological Upcoming — chronological Timeline — reverse chronological Ideally, users need the ability to define a global date sort for all sections, or to configure the date sort for each section separately. ... Exibir mais

When HubSpot forms are embedded on external websites using the standard embed code, reCAPTCHA (v2 Enterprise, invisible mode) fails to initialise if the host platform wraps the embed inside its own cross-origin iframe. This affects platforms like Cvent, which use iframe isolation for embedded widgets. The browser console shows "Invalid domain for site key" and reCAPTCHA timeout errors. The form cannot be submitted. This is not a domain allowlisting issue. HubSpot's reCAPTCHA site key has domain verification disabled. The failure occurs because Google's reCAPTCHA cannot validate origin trust or access behavioural/cookie signals when running inside a nested, cross-origin iframe controlled by the host platform. Current workarounds: 1. Remove reCAPTCHA from the form (loses spam protection) 2. Use the HubSpot share link inside an iframe instead of the embed code (works, but requires replacing every embed across every site) Neither workaround scales well for organisations with many forms embedded across many external websites. Requested improvement: HubSpot should handle reCAPTCHA in a way that works inside third party iframe containers, or provide a configuration option that allows the standard embed code to function in these contexts without requiring customers to switch to the share link for every form. Use case: Event management organisations using Cvent (and similar platforms) to host registration and contact forms powered by HubSpot across dozens of event websites. ... Exibir mais

HubSpot has made strong progress in centralising communication, but email organisation still lags behind. Many teams continue to rely on tools like Front because HubSpot lacks the structure needed to properly manage shared inboxes and historical communication at scale.   Key gaps: No native folder structure for organising important emails Limited filtering and view creation for email records Difficult to track emails by sender, tags, or CRM properties Heavy reliance on external inbox tools for proper management Proposed solution(s): Introduce Inbox folders for categorising emails (internal, partners, escalations, etc.) Expand filters to include; Sender / domain Tags Associated object properties (contacts, companies, deals, tickets) Enable shared, saveable views for team collaboration This is about unlocking the value of email data. High-quality CRM data needs to be accessible and usable across the platform, and while HubSpot is improving centralised email management, this is the next logical step. It also sets the foundation for AI to automatically categorise and prioritise conversations .   If HubSpot can match what dedicated inbox tools already do well, it would reduce tool sprawl and strengthen its position as a truly unified CRM. ... Exibir mais

It would be helpful to update the list of "idea categories" in this form, as topics like Breeze, AI, Agent... are missing, which is a shame. Thabk you very much ... Exibir mais

1. Year-Based Discounting for Multi-Year Contracts Our standard sales motion includes multi-year agreements (typically 36 months) with different pricing or discounts applied by year (e.g., discounted Year 1, standard Years 2–3). Currently, HubSpot does not support applying discounts by year within a single subscription. Attempting to model this with multiple line items breaks ACV calculations and causes ACV to match TCV, which impacts reporting and forecasting. What we need: Ability to define pricing or discounts by year within a single multi-year subscription Maintain accurate ACV vs. TCV calculations regardless of structure ⸻ 2. Flexible Contract Terms We occasionally have non-standard contract terms (e.g., 40-month agreements), but HubSpot only supports clean 12/24/36 month structures in a way that ties correctly to reporting. What we need: Support for flexible term lengths beyond standard yearly increments Accurate prorating and reporting across custom term durations ⸻ 3. Minimum/Base Fee Logic within Tiered Pricing Our pricing model includes a minimum annual fee below a certain threshold, which cannot be natively enforced within HubSpot’s tiered pricing model. Current workaround requires separate products, which introduces complexity and inconsistency. What we need: Ability to define a base/minimum fee within tiered pricing logic Conditional pricing rules (e.g., “if below X, apply minimum fee”) ... Exibir mais