For more granular permissions, you can configure at the playbook level - https://cloud.google.com/chronicle/docs/soar/respond/working-with-playbooks/playbook-permissions

Thanks, @cmorris .

I checked this solution, but unfortunately, it didn’t work in my scenario. In our case, all SOC team members have default view access to playbooks and blocks.

When I assign specific permissions to someone who is already part of the SOC group, it doesn’t override the default permissions for that playbook. The reason is that explicit permissions only grant access, not restrict it. Since the SOC group already has view access by default, adding someone from that group explicitly with view access doesn’t change anything for the rest of the group.

Is there any other way to handle this? Your help would be greatly appreciated.

Maybe this would work? I have something similar in that we have L1's, L2's and L3's. They have access to different functions. I created a menu system and they each have their own menu. 

the IDE of the menu

The block does whatever they picked, and then launches a playbook that calls the same block. It also allows you to get around that pesky 10 playbook thing

This as an example would be our L1 workstation playbook options. 

FYI, we also do the same type of thing with closing playbooks. Everything is menu-driven.