Les grands esprits se rencontrent

Had a client ask, "I've been entering notes under company records. But I don’t remember what companies now. Is there was to filter to see companies that have notes under them?"   We can see associated notes on the index page, but it's not a filter for "associated notes is yes" or something similar. That would be great!  ... Afficher plus

Currently, dealing with (hidden) fields in existing forms requires manually editing each form individually. This process becomes time-consuming and tedious, especially for organizations managing numerous forms with multiple (hidden) fields that change over time.   I'm especially thinking about hidden fields for language or utm-parameters:   Hidden fields typically used in multiple HubSpot forms   We recently decided to add another hidden field, so we had no other choice but open each form individually to do so.   It would be nice to have a feature that allows users to add (hidden) fields to multiple forms simultaneously. This functionality would significantly streamline form management, particularly for hidden fields whose placement within the form is not critical. Plus, it would reduce the potential for oversight when updating form structures. ... Afficher plus

We would like to be able to dynamically change the consent options shown to website visitors in a form depending on their country.  Different countries have very different data privacy and consent management requirements now, and it would be very useful to only gather the consent required for that region. The existing logic for dependent fields could be used, so then when a visitor selects a country from a field drop-down, a country-specific set of communication consent and privacy options show. It would be useful to still have a "default" set so that the HubSpot user doesn't have to create dependent consent options for every country in their drop-down field. ... Afficher plus

The new Beta form doesn't allow the use of properties from custom objects, it would be wonderful to have that ability on the Legacy Form.  The lack of this ability causes unneeded properties to be created so we can then workflow the property to the Custom Object/Create the Record in the Custom Object. ... Afficher plus

It would be really useful to be able to create associations and update association labels in Lead based workflows. Leads can be manually associated to other record types so I don't see why these associations can't be automated like they can be for other objects. ... Afficher plus

It would be nice to have the option to sort goals by performance or other custom columns in order to ease the process of focusing on goals per performance. ... Afficher plus

Hi!   I'm creating this on behalf of a customer.    It would be helpful to add the ability to notify Deal Collaborators on any Tasks that are associated on Deal records and are assigned to the Deal Owners.    The example use case shared by the customer is that - if they have a Deal that is sitting in the quote stage for more than 2 weeks, they have a workflow that will create a Task that will be assigned to the Deal Owner to remind them to follow up on the quote. They need that reminder or notification to go to the Deal's Deal Collaborator as well, not just the Deal Owner, since the Deal Collaborator oversees the Deal too. This can help them improve their process.    There is a potential workaround of creating a custom user deal property, then creating a duplicate Task in the workflow to be assigned to the custom user deal property, however, it would be more efficient and less data-cluttering if there can just be one single Task created in this case, and have the ability to notify both the Deal Owner and the Deal Collaborator on the Task.    Thank you!  ... Afficher plus

Hello,   My team and I have been working on implementing some regularly scheduled emails for our clients using HubSpot's Transactional Email API + the beta custom coded template/module features.    These emails are really more like marketing emails, but to leverage hubspot's single send API features we've been implementing them as transactional emails (it best suits our use-case for a range of reasons; for example, because there's a lot of bespoke data that needs to be pulled into the emails per-client in our backend, and which we don't want to store on HubSpot). Overall our desired implementation has gone well and the emails are almost ready to ship.   We've included unsubscribe links in the email footer which leverage our own unsubscribe solution, since these are going to act more like marketing emails and need to comply with relevant regulations. The unsubscribe url – which we're sending as a customProperty with the api request, and then implementing in the template – points to an endpoint of ours which implements in-house unsubscribe logic. This is important to us because we want our clients to be able to manage their subscription status both in-platform (ours) and through clicking the unsubscribe link.    The above setup for a footer unsubscribe link is working well. But to get to the point here, as a final step we want to implement those same unsubscribe links with List-Unsubscribe and List-Unsubscribe-Post headers for these emails, to comply with recently announced requirements from Google and Yahoo for marketing emails. I recently made a post on Hubspot Community inquiring whether it is possible to somehow specify values for these headers somewhere in the Transactional Email/Single-Send API flow, and per your Community Manager (and my scouring of HubSpot documentation) it looks like this is not currently supported.   This seems like a relatively simple ask and one that we'd like to formally request. From skimming around the web it looks like many email services are adding manual support here, including for teams like us with their own unsubscribe solutions: here's an example from Postmark showing what looks like a relatively straightforward manual implementation (the two headers and their values getting sent inside a "Headers" list with the API request). Is this something Hubspot can implement for its Transactional Email/Single Send API?   TL;DR: Enable specification of values for List-Unsubscribe and List-Unsubscribe-Post headers within API requests to HubSpot's Transactional Email / Single-Send API (example implementation from PostMark here), in support of compliance with Google/Yahoo requirements, for teams that need to implement an in-house unsubscribe solution with that API. ... Afficher plus

The introduction of the Object Library opens up a huge opportunity to become more plug-and-play for non-SaaS industries like Manufacturing. One problem I hope to alleviate with this idea thread is the fact that so many of us serving manufacturing are building and solutioning in silos right now. Without a community-led effort to support a Manufacturing Data Template in HubSpot, it will be very difficult for HubSpot to provide a template free of the need for custom objects. In my opinion, no need for custom objects is one of the biggest benefits of the new Object Library. I think we can get there. Here's how. Here are the native CRM objects that can be leveraged by most all manufacturing companies: Contact Company Product Marketing Events Lead Deal Line Item Quote Cart Payment Link Order Invoice Payment Subscription Ticket Appointment Course Service While Appointments, Courses, Services were not meant for manufacturing, it is not hard to adapt them to use cases like Field Services, Product and Application training, and Repairs and Preventative Maintenance contracts. But where does leave us for use cases like inventory, logistics, and quality management. Without templated objects like Assets, Installs, Shipments, Warranties, etc. we will still need access to custom objects to complete the customer-centric manufacturing data model. Now, I am not suggesting that we are trying to replace inventory management systems, accounting systems, and ERPs. They all have their place and have functionality that, IMO, we should not try to replicate in HubSpot. What we do need is a place in HubSpot for all of the data our customer-facing teams need to serve great customer experiences. Instead of creating object "creep" and a lack of standardization for the manufacturing industry, I think we can solve for all of these different post-sales use cases with one object.   I call it the "Deliverable".   Just like the Product object is designed in a general way to serve any product/service/experience a HubSpot customer might provide, the Deliverable object can be thought of in the same way. I think of it like this... The Product Library is the strategic, pre-planned version of what you want to sell.   Line items are the ultra-customizable version that help close the sale based on specific customer need. Not to be changed post-sale.   Deliverables are what was promised to the customer at the close AND any other deliverables needed to support that promise. (Ex. Warranty) Put simply: Product <> Line Item > Deliverable I have been working with Deliverables as a custom object and the magic is in leveraging Pipeline functionality. So, instead of easily coming up with 5-10 more CRM objects, I believe we can serve known use cases with Pipelines instead. This also allows for customized configuration for each business via new pipelines instead of new objects.   The "stage-and-gate" nature of pipelines not only unlock the rest of the HubSpot Customer Platform, they also create the perfect place for data coming from other systems that manage inventory, production, purchasing, and accouting processes. Think of Product, Item, Expense, and Order pipelines that are found in other systems. See the NetSuite Integration as an example of what I mean Let this post not be seen as the final solution, but simply a means to support the HubSpot team trying to give us a sustainable one. I'll be sharing more links and diagrams in support of this discussion and I hope the community will feel safe and motivated to do the same. Let's Build! ... Afficher plus