Great minds think alike

HubSpot admins need to be able to prevent users from accessing the "edit columns" (see below) button while working in the Line Items editor / in the Quote tool.   Currently, users see the button "edit columns" and they are free to take advantage of making the tool suitable for their personal needs. This, in turn, complicates the lives of their colleagues and HubSpot admins.  As a CRM aimed at scaling businesses & enterprise customers, HubSpot should prioritize such an update with high priority.     ...read more

HubSpot currently does not allow SuperAdmins to edit certain HubSpot specific properties like 'Became a Customer Date' aren't able to be edited.   We need the ability to adjust some of these properties because sometimes they may be updated incorrectly and need to be changed after the fact.   A recent example was we had a two records that had different Became a Customer Dates. When merged, it defaults to updating the most recent value, however for our purposes, we wanted to update it to the previous value and are unable to do so.   We can currently edit all custom HubSpot properties, expanding that list would be beneficial for all.     ...read more

We would like to add a feature that prevents that emails can be send out to recipients that are outside the responsible area of a user or team that sends out the email. For example, we want to ensure that an email originating from Spain cannot be sent out by mistake to another country like the Netherlands without proper permission. Background of the idea Currently, there is a possibility of sending out such emails by mistake, leading to people receiving unwanted emails. We know these mistakes can be prevented manually, but relying solely on manual actions to prevent this, is prone to human errors. Therefore, we propose to prevent this within HubSpot's basic configuration too. Moreover, in many countries, legal requirements such as GDPR emphasize the importance of taking all necessary measures to prevent the send out of unwanted emails. Our specific request to HubSpot is to add a checkbox in the settings that restricts email send-outs to the user's responsible area. In cases where someone needs to send emails to multiple areas for which they have no permissions, they can be designated as super admins. However, a warning message should be displayed to indicate the associated risks. Let's help eachother to prevent these mistakes by all means possible. ...read more

When accessing our sales reps calendars via the "Prospecting" page, I would like to see the details of their meetings vs. just seeing "Busy".  Would like to have it open, as a choice, to all; managers; admins - as examples.  Prefer to NOT have to leave Hubspot and look in outlook.   ...read more

Hi,   Our marketing permission set use to allow our marketing team to create their own simple workflows / automations as a follow-up for emails or form submissions.   Now, simple workflows and complex workflow access seem to be merged. This means our marketing team either: Contact admin to set up simple workflows per email/form Receive access to all workflow capabilities However, we want to minimise the access for the latter to admins only.   Can we separate permissions for simple workflows away from workflows in general?   Kind regards,   Jason ...read more

Currently, we can restrict users from installing an app from the HubSpot marketplace but there is no setting under user permission that allows us to restrict a user from accessing or editing the native integration settings. For example, if we are using the HubSpot - Salesforce native integration (Salesforce Connector) there is no way we can define the users who have access to editing or updating the app settings in HubSpot. This is very important as it creates a huge risk if multiple users can edit the integration settings. ...read more

I want to suggust to the HS product team that you address some of the limitations to Team membership.    I recently learned that if a user is listed in a team as an 'Extra' team member, that this limits certain functions. For one thing, they cannot be included in round robins.    I was excited by the potential for adding nested teams/subteams to larger teams, and adding users as 'extra' team members, as I felt this would provide several benefits.    Example A: Regional sales team round robins.    We have a team for our Enterprise Sales Department called "Enteprise Sales" the team includes any and all enterprise sales staff.    I went and created 2 subteams: Enterprise East, and Enterprise West, since certain staff are assigned to west coast leads, and some are assigned to east coast leads. However, the sales reps had the East/West teams as their 'extra' team membership, and so when I went to add those nested teams to the round robin I discovered I wasn't allowed to because 'extra' team members do not show up in round robins, and the east/west teams consisted entirely of 'extra' team members.   At first I thought this was a simple fix and I could just make the 'parent' departmental enterprise sales team to their 'extra' team membership (since it isn't as important from workflows.)    However, that ultimately did not appear to be an option, since 'extra' team members are not included on reports that are filtered by teams, and we have many dashboards/reports that are filtered on the primary, departmental, 'enterprise sales' team.    2.) Workflow maintenance   Another reason I was excited for subteams and 'extra team' memberships was because I thought it would make workflows much easier to manage moving forward, especially as our company continues to grow and expand.    For example: the average sales rep with a HS user account is incorporated into dozens of workflows. In the event that a sales rep leaves the company, or changes positions, we have to remember the 12+ workflows that need their steps and branches to be edited and updated whenever a staff person needs to be added or replaced.    A HUGE improvement would be to create subteams that only include 1 single user (for example: creat a Subteam called "Regional Sales Manager: Florida" and then assign the Florida regional sales manager as the one and only team member.)  Then our plan was to edit all of our workflows so that no branch is ever based around a specific user account, but rather steps and branches are based around that user's unique subteam. That way, if our Florida Regional Sales Manager leaves the company or changes roles, and somebody new is placed in that position, the only thing I need to edit is that new user's HubSpot Subteam, as opposed to spending tons of time editing dozens of workflows, and risking forgetting or neglecting to update one or two.  I'm honestly not certain what the function or utility is to subteams and 'extra VS main' team membership if users are limited to 1 main team and 'extra team' membership limits reporting, round robins, routing and notifications. Freeing it up so that people can be on multiple teams and still have all of the available features of a 'main team member' seems like it would 10x the value of having users on multiple teams.    I hope this feedback is helpful.  ...read more

Sometimes, I need to archive properties no longer in use, or, wish to change the field. If these proeprties are being used in views created by others, I am unable to remove the properties and have to either go round asking people to remove them and save, which is so time consuming and just annoying, or just delete the view completely   Super admins should have the ability to remove these fields and save on behalf of the owner, please update this! ...read more

Hey HubSpot,   We'd love to see something in the way of adding conditional logic as to WHEN somebody can edit a property rather than just WHO can edit/see etc   E.g When the Deal is Deal Stage "Pending Approval", properties such as "Conditions", "Amount", "Submission Date" cannot be updated.   This would allow for greater confidence and control around time crititcal processes and ensuring that information is not being incorrectly updated after a submission where details must remain the same for verification purposes etc   Ideally this would be similar to, but is not quite the same as User Permissions on Properties.   Thanks! ...read more