Great minds think alike

1: There are too many timezones available on the contact timezone field - it should be one option per actual timezone. Currently in Hubspot I see over 200 possibly more (takes too long to count because there are so many).    2. This would be simplified and the problem erased if you could properly order the timezone on the tasks section. Currently, the tasks, if ordered by timezone, are ordered by alphabetical name of the timezone! Which completely defeats the point of having a timezone in the first place. It should be ordered: UTC-12, UTC-11, UTC-10 and so on. Currently it is ordered: UTC -6 US Mountain, UTC -4 US Eastern, UTC -5 US Central. The most frustrating part of all of this is that, when it comes to making a selection from the drop down menu of Timezones on the contact field, it is ordered in the second, more useful way: UTC-12, UTC-11, UTC-10 and so on. Suggesting that this should be an easy fix.   Tasks ordered by Timezone field:    Timezone field dropdown menu:  ...read more

Idea Description Currently, Sensitive Data properties can be added directly to native record creation forms (e.g., Ticket creation forms) as standalone fields, but they cannot be used as dependent or controlling fields within conditional logic. This creates an important limitation in real-world workflows. In many operational scenarios, sensitive information is only required for specific record types or ticket categories, not for every submission. For example: A sensitive field should only appear when a specific Ticket Type or Category is selected. The field should remain hidden otherwise, to avoid unnecessary exposure and to keep forms clean and efficient. At the moment: The Sensitive Data property is allowed on the form But disappears from the selector when trying to apply conditional logic This suggests that conditional logic is not yet enabled to interact with the security/encryption layer of Sensitive Data properties Business Impact Forces teams to either: Show sensitive fields at all times (poor UX and security exposure), or Use workarounds outside native forms (custom UIs, integrations, or manual processes) Reduces adoption of Sensitive Data properties in structured, compliant workflows Impacts regulated environments where data minimization and context-based collection are mandatory Proposed Enhancement Enable Sensitive Data properties to: Act as dependent fields in conditional logic Be shown or hidden based on the value of non-sensitive controlling fields While maintaining their existing encryption, access controls, and audit protections This would allow teams to: Collect sensitive data only when necessary Preserve security standards Fully leverage native HubSpot forms without custom development This enhancement would significantly improve usability for enterprise and compliance-driven customers while staying aligned with HubSpot’s security model. ...read more

💡 Idea Title Allow Conditional Properties to Be Automatically Expanded in Record View for Read-Only Users 📝 Idea Description Currently, when properties are shown based on conditional logic (for example, properties that appear depending on a Ticket Type or another controlling field), those properties only become visible after a triggering interaction or edit event. However, there is no way to force these conditional properties to automatically appear expanded in the record view for users with read-only permissions. 🎯 The Use Case In many organizations: Certain ticket properties are populated via forms. These properties are shown conditionally depending on a selected value (e.g., Ticket Type, Category, etc.). Some users (such as auditors, supervisors, compliance teams, or operational reviewers) only have view permissions, not edit access. The issue is: If the conditional field was already populated via a form, users with read-only access may not see all related conditional fields clearly displayed unless a change or edit interaction occurs — which they are not allowed to perform. This creates friction in review workflows and visibility processes. 💼 Business Impact Read-only users cannot easily review all relevant data. Supervisors and compliance teams may miss context-specific fields. Forces organizations to either: Grant unnecessary edit permissions, or Duplicate properties into non-conditional groups, reducing form logic efficiency. In regulated or audit-heavy environments, full visibility without edit capability is critical. ✅ Proposed Enhancement Allow administrators to configure conditional properties so that: If the controlling condition is already met, And the property contains a value, The property automatically appears expanded/visible in the record view, Even for users with read-only permissions. This would: Improve transparency Preserve permission boundaries Support enterprise and compliance use cases Enhance usability without compromising security ...read more

We would really value a native HubSpot property that calculates the most recent completed meeting, based on meeting start time/activity date, not updated or create date. In our business: - Users log both scheduled and completed meetings. - Meeting outcomes are often updated late (sometimes weeks after the meeting occurred which is totally user error). - As a result, “most recently updated meeting” and “last meeting activity” regularly point to the wrong meeting. - Scheduled future meetings also contaminate any “most recent meeting” logic unless outcome is explicitly respected. What’s missing today is a property that: - Considers only meetings with outcome = Completed - Uses the meeting start time/activity date as the anchor - Always resolves to the latest qualifying meeting, regardless of when it was logged or updated - Is usable in filters, workflows, lists, and reporting This is a super common sales and account-management metric (“days since last completed meeting”), and currently requires fragile custom workflows to approximate. A native, outcome-aware rollup would materially improve data reliability for teams at scale. Please consider creating something like this 🙂 Thank you! ...read more

This idea is primarily for developers, technical admins, and advanced HubSpot users who regularly work with the CRM APIs, custom code actions, integrations, or external systems. Problem: Today, the only way to see a property’s internal name is to click into each individual property. When you’re working with APIs or external tools, internal names are what actually matter — not labels. If you need to reference or validate many properties at once, this becomes extremely time-consuming and disruptive. You’re forced into a repetitive loop of opening properties one by one just to copy a single value. Proposed Improvement: Add Internal Name as an optional, visible column in the Properties table (similar to how names, groups, and access types are shown). Ideally, this column would also be searchable and sortable. Why This Matters: Dramatically improves developer and admin efficiency Reduces friction when building integrations, workflows, and custom code Makes property audits and troubleshooting far easier Aligns the UI with how properties are actually used in APIs and automation This small UI enhancement would save significant time for anyone working at scale with HubSpot data and would meaningfully improve the developer experience across the platform. ...read more

We need the ability to append custom single-line and multi-line text values when merging records or in a workflow (where the "append" option is missing).   As an agency, we use a custom text property to house Partner IDs for our brands inside different PRMs, but we often run into the case where major publishers have multiple IDs; since we use it as a unique identifier, this creates duplicates that, when merged, remove the alternative IDs that we need to see.   Some publishers will use a dozen or more Parner IDs and we need to see all of them in their company records.   Currently, the only solution is to review the history of the property and append the values manually (which is too time-consuming to sustain as a practice), or download our duplicate companies every week or two and append the values in a spreadsheet, then import them back into the system and proceed to merge the duplicate records.   Neither of these solutions are what you'd expect from a professional CRM like HubSpot, and we need a better way.   It would also be great if we could retrive and append values from a property's history in a workflow as well. ...read more

The ability to assgin an owner on a round robin basis, controlled by a multiple user field. Example, Custom Object Record has 3 users selected in a "Sales Reps" - User field. A deal is created & associated to the Custom Object Record. Assign the deal owner to one of the "Sales Reps" on a round robin basis ...read more

Hi, When creating a rollup property there is no such option to multiselect like if a property is dropdown there is still = opertor there and for logical conditions there is only AND no OR.  ...read more

Some of my customers wish that their CRM Users see fields that are created as "single Checkbox" as a "Checkbox" field (to check/uncheck) in the left column on object level (and other places). I am very surprised that this is only possible in forms. Why can't I change the visualization from "dropdown" to a "Checkbox"? ...read more