The playbook creator can define view and edit permissions for users per
playbook. This means you can restrict access for specific users or SOC roles to
edit certain playbooks.
Here are some examples of MSSP use cases for playbook permissions:
Allow end customers (managed-plus users) to build playbooks in their own
environment while collaborating with MSSP engineers
Allow MSSPs to create playbooks without giving edit permissions to their end
customers (managed-plus users)
Here are some examples of Enterprise use cases for playbook permissions:
Restrict edit access of certain engineers to sensitive playbooks
Prevent engineers from overriding your work while building a playbook
The Permissions icon is located on the top right of the Playbooks
page.
The Playbook access permissions dialog is displayed.
At the very top of the Playbook access permissions dialog is the
Default Permissions section. This focuses on all the users who have
access to all the environments that the playbook can run on. You can choose here
to let all the users view this playbook or allow them to make changes. You have
to have access to all the environments the playbook runs on in order to have
editing rights. However, you only need access to one environment in order to
have viewing rights.
The Specific permissions section allows for more granular flexibility in
drilling down to specific users or SOC roles within specific groups to grant
them either edit and view access. Permissions selected here override the default
permissions that were previously set.
You can configure specific permissions for individual users or for SOC Roles.
SOC Roles can be assigned to both users and API keys.
So for example, you could tag Tier 3 as view only and select Alex Smith (who is
in Tier 3) as having edit permissions.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003ePlaybook creators can define view and edit permissions for individual users or SOC roles, enabling control over who can modify specific playbooks.\u003c/p\u003e\n"],["\u003cp\u003eDefault permissions allow setting access rights for all users across all environments where the playbook operates, with edit access requiring access to all environments and view access needing only one.\u003c/p\u003e\n"],["\u003cp\u003eSpecific permissions enable fine-grained control, allowing for the assignment of distinct edit or view access to individual users or SOC roles within particular groups, overriding the default permissions settings.\u003c/p\u003e\n"],["\u003cp\u003ePlaybook permissions support various use cases, including enabling collaboration between MSSPs and their customers, restricting access to sensitive playbooks, and preventing unintended modifications by engineers.\u003c/p\u003e\n"]]],[],null,["# Playbook permissions\n====================\n\nSupported in: \nGoogle secops [SOAR](/chronicle/docs/secops/google-secops-soar-toc) \n\nThe playbook creator can define view and edit permissions for users per\nplaybook. This means you can restrict access for specific users or SOC roles to\nedit certain playbooks.\n\n\nHere are some examples of MSSP use cases for playbook permissions:\n\n- Allow end customers (managed-plus users) to build playbooks in their own environment while collaborating with MSSP engineers\n- Allow MSSPs to create playbooks without giving edit permissions to their end customers (managed-plus users)\n\n\nHere are some examples of Enterprise use cases for playbook permissions:\n\n- Restrict edit access of certain engineers to sensitive playbooks\n- Prevent engineers from overriding your work while building a playbook \n\nThe Permissions icon is located on the top right of the **Playbooks**\npage. \n\n[](/static/chronicle/images/soar/playbookpermissions2.png)\n\n\nThe **Playbook access permissions** dialog is displayed.\n[](/static/chronicle/images/soar/playbookpermissions1.png)\n\n\nAt the very top of the **Playbook access permissions** dialog is the\n**Default Permissions** section. This focuses on all the users who have\naccess to all the environments that the playbook can run on. You can choose here\nto let all the users view this playbook or allow them to make changes. You have\nto have access to all the environments the playbook runs on in order to have\nediting rights. However, you only need access to one environment in order to\nhave viewing rights.\n\n\nThe **Specific permissions** section allows for more granular flexibility in\ndrilling down to specific users or SOC roles within specific groups to grant\nthem either edit and view access. Permissions selected here override the default\npermissions that were previously set.\n\n\nYou can configure specific permissions for individual users or for SOC Roles.\nSOC Roles can be assigned to both users and API keys.\n\n\nSo for example, you could tag Tier 3 as view only and select Alex Smith (who is\nin Tier 3) as having edit permissions.\n\n\u003cbr /\u003e\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]