Behavior Change Release Process

Learn about Immuta’s behavior change release process so you can plan feature adoption

The behavior change release process allows you to control whether a product change that affects existing functionality is enabled for your account before the changes are enabled across all accounts. Generally, Immuta allows you to opt in or out of a feature change for two months before the feature is enabled for all accounts. However, Immuta may provide more time for specific changes that require more lead-time, such as API changes.

The stages of this process are described below. If a feature change qualifies for the behavior change release process, specific dates for each stage will be provided in the deployment notes. See a list of all the features on the Behavior change release features page.

1

Opt-in period

For the first month after a change is released, it is disabled by default for all accounts. The feature change will not be released to any customers who have not opted in. If you have a non-prod environment, it is recommended that you take advantage of this opt-in period on that non-prod environment.

Contact your Immuta representative or submit a support ticket to enable the feature change during this period.

2

On by default period

During the second month after a change is released, it is on by default for all accounts. However, the feature change will not be released to any customers who have opted out.

Contact your Immuta representative or submit a support ticket to opt out before this period. A behavior change feature cannot be disabled after it has already been enabled.

3

Enabled for all accounts

At the end of the opt-out period, the feature change is enabled for all accounts.

Immuta no longer offers the option to opt out of the change.

Qualification for a behavior change

A behavior change is defined as any change to existing behavior that returns different results from before and may impact customer code or workloads. Migrations that impact customer-authored configurations, such as policies or settings, may also fall in this category even if the functional results remain the same post migration.