Several departments within the company use HubSpot, and it is a major issue that all users with Sales or Service seats can access the Help Desk without restrictions.
We cannot risk, for example, a salesperson responding to an email using the finance team’s address registered in the Help Desk as a channel. This is a significant limitation of the tool, which makes the teams’ routines increasingly less automated.
I agree, there needs to be a way to better lock down the settings for the Inbox and Help Desk so that on the appropriate teams can make changes.
Yes this is an issue we face too, I’ve just come across a problem where a sales user needed to reconnect their inbox to Outlook, but in HubSpot when they go to create an email from the contact record, the helpdesk email is appearing as an automatic ‘from email’ fallback.
The sales user does not need access to helpdesk and but has accidentally created a few items in helpdesk by unknowingly sending emails from their helpdesk ‘fallback’ email.
We’ve only been testing out helpdesk as a solution so the problem hasn’t happened at a large scale, but it appears that for any service/support projects we might embark on in the future, we’d have to revert back to an inbox and ticket pipeline to lock down access to a single team.
I support everything stated above; we are experiencing the same issues.
Greetings Help Desk admins, partners and enthusiasts! Trying to get an early signal on different solution paths to the problem stated in this Idea
People who ‘shouldn’t be able to’ (like sales reps) are able to send from a Help Desk email address when using a communicator on a CRM record page.
Long-term, we completely understand there is an appetite for more granular permissions in Help Desk, like restricting certain teams to certain channels. Near-term, Help Desk does not have an access model like how Conversations Inboxes could be locked down to specific teams.’ Help Desk Access’ includes ability to view tickets, conversations, and even send messages - today Help Desk Access is included with ‘Sales Access’ and ‘Service Access’ (see HubSpot permissions guide).
Would it suffice to tie “can use a HD email address as a from address on an object-page communicator” to ‘Service Access’? That would be a quick easy thing for us do. And ‘Service Access’ can be included or not included in any of your permission sets.
Or, is this too broad strokes of a solution, aka, you rely on other features in ‘Service Access’ (like Feedback surveys or creating Templates) for some of your ‘non support teams’?
Hi Eric. I am not sure I understand your suggestion, but for us we would like only certain teams to have access to specific “from” addresses. So one team may be emailing from HelpDesk with X email and then another team needs to be using Y email and they should not be seeing any other emails as an option to send from if they don’t have permissions to do so.
Hi @EricHirsh,
Thanks for sharing your team’s perspective on this topic.
We cannot speak for every use case, but for our company, this limitation is exactly why we are still using the Conversations Inbox instead of migrating to Help Desk. Our team structure depends on separating channels by product and responsibility. For example, Product A is handled by one team, Product B is handled by another team, and then we have managers who oversee multiple channels depending on their role. Today, we can support that structure in Conversations Inbox. In Help Desk, we cannot.
Because Help Desk does not currently allow this level of granular access control, moving to it would mean exposing channels to users who should not be seeing them. For example, Product A’s support team could end up seeing Product B’s inbox or related conversations, even though that information is irrelevant to their role and, in some cases, not something they should have access to at all.
That is the main blocker for us. HubSpot has clearly shifted a lot of product investment and important updates toward Help Desk as the successor to Conversations Inbox, which makes sense. But without more granular permissions, we are effectively unable to migrate, even though we would like to.
As end users, we also understand there may be backend or architectural reasons why this is difficult to implement in Help Desk the same way it worked with inboxes. We cannot speak to that side of it. But one possible path that may make this easier is to build on the existing Help Desk Spaces feature.
From our perspective, Spaces already closely resemble how Conversations Inboxes are used in practice. We have mentioned this in another post before, but Help Desk Spaces really should be a standard feature available to all relevant users, rather than something limited only to Service seat users. At the moment, Spaces feel very similar to saved views, and view customization is already a normal and widely available concept across HubSpot. If Spaces were made more broadly available, they could potentially become the foundation for more granular Help Desk access. For example, users could be restricted so they can only access or view tickets within specific Spaces, similar to how teams are currently separated by inbox in Conversations Inbox.
That kind of setup would make Help Desk much more realistic for companies like ours to adopt, while also helping preserve the operational boundaries teams need for clarity, relevance, and privacy.
Hello all, a partial solution to this problem is now Live. It is what I mentioned earlier in this thread.
Admins can now restrict which users can select a Help Desk email address as the From address when sending or replying to a one-to-one email on a record page. Now team email accounts connected to Help Desk will only be available as a From address on a record page for users with the Service Access permission. Product update.
However, we absolutely understand many of you are blocked on migrating from Inbox to Help Desk until the latter can support more granular permissions. That project is now in planning! I’ll leave this idea as ‘In Development’ until there are updates on the availability of the full permissions solution.