Feature · Platform
Policies
Set what workers may do and when they need approval.
How it works
Effects
- Allow: the worker acts on its own.
- Notify: the worker acts, then tells people.
- Require approval: a person approves before it runs.
- Deny: never allowed.
Which policy wins
The most specific scope wins: worker, then role, team and organization. Priority breaks ties within a scope. When a tie remains, deny wins. A call that no policy matches gets the default for its risk tier.
Defaults
Without policies, low-risk actions run, medium-risk actions run and notify, high-risk actions such as merges need approval, and critical actions are refused. The autonomy mode and the Always ask list can hold an action for approval too.
The page
Policies has two tabs: Rules and Simulator. Use the simulator to test which policy applies to a call. Only owners and admins can add, enable or disable a policy.
From the help article Policies, checked against the product on .
What you can do
The operations this feature's screens call. Each one is POST /api/<name>, and the badge says who may call it.
ViewerlistPoliciesLists policies.
Types:
ListPoliciesRequestreturnsListResponse<PolicyDto>
ViewerlistRolesLists roles.
Types:
EmptyRequestreturnsListResponse<RoleDto>
ViewerlistConnectorsLists connectors.
Types:
EmptyRequestreturnsListResponse<ConnectorDto>
AdminNo API tokensupdatePolicyUpdates policy.
Types:
UpdatePolicyRequestreturnsPolicyDto
AdminNo API tokenscreatePolicyCreates policy.
Types:
CreatePolicyRequestreturnsPolicyDto
AdminNo API tokensdeletePolicyDeletes policy.
Types:
PolicyIdRequestreturnsOkResponse
ViewersimulatePolicySimulates policy.
Types:
SimulatePolicyRequestreturnsSimulatePolicyResponse
ViewerlistMembersLists members.
Types:
EmptyRequestreturnsListMembersResponse
Screens
What it records
The feature writes these events to the audit log, the permanent record of what happened.
- Integration changed