Rollout allow you to control the deployment schedule as well as communications with application team, for example:

The following examples use terraform to illustrate the capabilities of a rollout, but you can create a rollout from the console if you prefer.

A rollout should include at least one guardrail. Once the rollout starts, you cannot be subsequently add, remove, or change the guardrails. You may add or remove accounts after the rollout starts, but you will usually want to include all the accounts before you move beyond the `draft` phase.

All dates are "absolute" in the rollout, but you can use HCL functions to make them relative. This makes it easier to manage the plan if dates change in the future since they tend to be related to each other.

If you want, you may use `start_early_if = "no_alerts"` automatically enter a phase when there are no alerts, regardless of the schedule. For example, accounts could go straight to enforce if they don't have any alarms for the controls in the rollout.

Note that by using the data source in the terraform plan, the account list will ONLY be updated if you re-run the plan; The list of accounts is resolved in the plan phase of the terraform run. If you want to update the list, you have to re-run the plan. The UI also makes it possible to add accounts by tag, even though they are stored internally as IDs.

Guardrails, on the other hand, cannot be added or removed once the rollout has started. If guardrails are added or removed that match the tag, then subsequent terraform runs will fail - the list of guardrails no longer match the current state, but you are not allowed to update them. To avoid this situation, you can use an `ignore_changes` lifecycle policy.

Rollouts provide a predictable way to roll out your guardrails. How to deploy them is up to you; many customer prefer to deploy small, incremental changes frequently, while others prefer larger, less frequent changes. Both options are possible with guardrails.

In either case, your policy posture is dynamic, and will change over time. As new guardrails are rolled out to existing accounts, they also need to be applied to new accounts, or existing accounts that are newly imported. You can use `tags` on guardrails to help define baselines and manage to a known set of guardrails.

- When *brand new accounts* are added, you can deploy the baseline by creating a rollout that includes all guardrails with the baseline tag(s). Since the accounts are new, you can probably move them straight to enforce (or use `start_early_if` to allow a relaxed scheduled but progress faster if there are no alarms).

- When *existing account are newly imported*, you may choose to deploy the baseline to bring them "up to standards". Alternatively, deploy guardrails iteratively in priority order until the baseline has been reached.

- You can *manage drift* and ensure accounts have the baseline installed. Because guardrails that are already in `enforce` will not be re-applied, simply create a deployment plan to apply the baseline and attach any accounts. Any "missing" guardrails will be deployed on the rollout schedule. Accounts that already meet the baseline will be unaffected, and will not receive any notices.

- There should be no warning or welcome notices from the `foo` for the `111111111111` account, because it is already in the `Check` phase. It would have already been sent warnings and/or welcome notices from the `bar` rollout.

- Warnings and welcome for the `Enforce` phase will be sent to `111111111111` from the the `foo` rollout, because `foo` rollout is scheduled to transition the account to `enforce` before `bar` will.

The guardrails for a rollout are set when the rollout starts, and cannot be subsequently changed

Likewise, you can pause a single account to "pin" it to its current phase. The behavior is the same as when the rollout is paused: While paused, no state transitions will occur and no notices will be sent. If you subsequently resume the rollout, any "missed" notices will not be sent, but the account will be moved to whatever state the rollout dictates, and will receive the "welcome" notice for that phase if it is transitioned due to the rollout.

If you attempt to delete a guardrail, or to edit a policy setting for a guardrail that is in `check` or `enforce` for any account, it will fail unless "forced". You must either: