Restrict the scope of access to smart lists

To date, on Hubspot, I’ve segmented access to Hubspot contacts by salesperson. This means that sales rep 1 can only see the contacts in batch 1, for example contacts A, B and C, while sales rep 2 can only see the contacts in batch 2, for example contacts D, E, F, etc.
However, when a sales rep wants to create a smart list, he has basic access to all the contacts. It is up to them to set up a filter so that they can then use the workflow to send the list only to the contacts they are attached to.

This makes no sense.

A sales rep can only see his contacts, but can send to all the contacts in the database.

What can I do to prevent this from happening? My aim is that the sales rep should not be able to access all the contacts via the smart lists.

Hey @AlexisData it’s not currently possible to have permissions that granular, the CRM permissions can enforce someone only being able to view their owner records but this doesn’t pull through to the workflow/list permissions. Once someone has permissions to create workflows, anyone enrolled in that workflow will be brought in.
In general, the CRM permissions would be for people who would more closely linked to the records (such as sales reps), in general it would be revops and super admins creating the workflows themselves. workflows and lists are much more of a “portal wide” tool than a granular user level tool.

I can see how this would be useful however, it would definitely be useful to add this to the ideas board to add a feature request for the HubSpot product team!

Thank you for your prompt reply.
What are the possible workarounds? A specific development (to block the workflow when the user is going to use a list that contains a contact to which he is not entitled)? A third-party application from the marketplace?

I’m honestly not aware of any to be honest, HubSpot doesn’t have a scopes api to allow third parties to define scopes and permissions in-app so it’s not really possible to have a third party app.

What I would probably do is task a specific admin for maintaining automation and have them implement it on behalf of the reps who should not be able to run automation on the entire portal.