docs: update rollout policy (#906)

* docs: update rollout policy

* chore: update

* chore: update

Author: boojack

mintlify/change-database/approval.mdx

@@ -77,4 +77,7 @@ Navigate to **Settings > Custom Approval > Rules**
 In your project settings, consider:
 
 - **Self-approval**: By default, users cannot approve their own changes. [Enable self-approval](/change-database/settings#self-approval) only if your process allows it
-- **Rollout Policy**: Define whether approved changes deploy automatically or require manual trigger via [rollout policy](/change-database/environment-policy/rollout-policy/)
+- **Rollout Policy**: Configure rollout requirements and permissions via [rollout policy](/change-database/environment-policy/rollout-policy/), including:
+  - Whether issue approval is required before rollout
+  - How plan checks should be enforced (block on errors only, errors and warnings, or allow rollout regardless)
+  - Whether changes deploy automatically or require manual trigger

mintlify/change-database/environment-policy/rollout-policy.mdx

@@ -9,27 +9,52 @@ title: Rollout Permissions
   horizontal
 />
 
-Configure who can deploy database changes in your environment through rollout permissions. You can choose between role-based deployment by authorized users or automatic deployment when all checks pass.
+Configure who can deploy database changes and what conditions must be met before rollout can proceed in each environment.
 
 ## Role-based rollout
 
 ### Default roles with permissions
 
 Users with the `bb.taskRuns.create` permission can perform rollouts. The following roles have this permission by default:
+
 - Workspace Admin
-- Workspace DBA 
+- Workspace DBA
 - Project Releaser
 
 ### Environment-specific roles
 
 If you want to use different roles to perform rollouts in different environments, you can specify environment-specific roles in the Environment policy settings. This allows you to control who can deploy changes to specific environments, such as having different teams responsible for staging versus production deployments.
 
+## Configurable rollout requirements
+
+Configure what conditions must be met before changes can be rolled out in each environment:
+
+### Require issue approval
+
+Ensures all changes are reviewed and approved before deployment to production environments. When enabled, issues must receive approval before rollout can proceed.
+
+**Default**: Enabled
+
+### Plan check enforcement
+
+Controls how rollout behaves based on plan check results, including SQL Review policy violations and other validations:
+
+- **Block on errors only** (default): Rollout is blocked if checks return errors, but warnings still allow rollout
+- **Block on errors and warnings**: Rollout is blocked if checks return either errors or warnings
+- **Allow rollout regardless**: Rollout can proceed even if checks return errors or warnings
+
+**Default**: Block on errors only
+
+<Note>
+Plan checks include [SQL Review policy](/sql-review/review-policy) violations and other automated validations configured for your environment.
+</Note>
 
 ## Automatic rollout
 
-Enable automatic deployment when all checks pass by selecting the `automatic` option. Failed checks will block automatic rollout:
+Enable automatic deployment when all checks pass by selecting the `automatic` option. This will automatically deploy changes when:
 
-- [SQL Review policy](/sql-review/review-policy) violations
+- All required approvals are obtained (if "Require Issue Approval" is enabled)
+- Plan checks pass according to the configured enforcement level
 
 <Note>
 Do not enable automatic rollout for GitOps Workflow as it can cause conflicts that result in failures.

mintlify/change-database/scheduled-rollout.mdx

@@ -33,7 +33,11 @@ This separation of concerns ensures that developers focus on creating quality mi
 
 ![rollout-schedule](/content/docs/change-database/scheduled-rollout/bb-rollout.webp)
 
-If there are any warnings or errors, as long as you check **Rollout anyway**, you can still schedule the time.
+If there are any warnings or errors, your ability to proceed depends on the [Plan Check Enforcement](/change-database/environment-policy/rollout-policy#plan-check-enforcement) settings configured for the environment:
+
+- **Block on errors only**: You can proceed if there are only warnings
+- **Block on errors and warnings**: You must resolve all errors and warnings before scheduling
+- **Allow rollout regardless**: You can proceed even with errors or warnings
 
 ![rollout-schedule-anyway](/content/docs/change-database/scheduled-rollout/bb-rollout-anyway.webp)