the Chromium logo

The Chromium Projects

Shipping changes that are enterprise-friendly

Shipping changes to enterprise customers requires some extra due-diligence.

Millions of users rely on Chromium browsers to do their job. For home use, we strive to make the browser as simple and safe as we can, by taking complex configurations off people's minds. However, in small and large enterprises, this is a task left to specialists who need their browser to fit in the complex puzzle of hardware and software that drives their organization. Enterprise customers:

Even changes that are not targeted for enterprises may still have an effect on them. (Non-exhaustive) examples:

Any change that's likely to affect enterprises should follow these guidelines, easing the burden for IT admins managing their fleets, and reducing the number of changes that need to be reverted from the stable channel.

How to ship enterprise-friendly changes

1. Give enterprises visibility

If your change has a Chrome launch bug, it includes an enterprise review. The enterprise team will use this as an input to the enterprise release notes, so no action is required from you yet.

If your change does not have a Chrome launch bug with an enterprise review, describe your planned changes by joining and emailing the chromium-enterprise technical discussion group, at least 3 milestones (~3 months) prior to launch to stable, and sooner than that for highly disruptive changes.


We will announce the changes in the "Coming Soon" section of the enterprise release notes before your change ships to stable and in the "This release" section when the change goes to stable. If you've announced the changes in the chromium-enterprise technical discussion group, or if it has a Chrome launch bug, the enterprise team will reach out to you to confirm the plan and the wording each time the release notes are written (don't worry if schedules have changed since last time; this is normal).

2. Give enterprises control

Include a policy to control the new change, where possible. The specifics depend on the exact change, but here's a best practice that works for most disruptive changes.

Introduce a policy that can force the new behavior on or force the behavior off. If the policy is not set (i.e. for consumers), the behavior is defined by a Finch config.

Can enterprise users set features directly?

We do not encourage enterprise users to use features or flags. Here are some reasons why:

  1. Features are mostly designed for experimental purposes. They can be added, modified, or removed easily. Policies, on the other hand, are more stable configurations. They require documentation for administrators and backward compatibility support.
  2. Features always apply to the whole browser instance and need to be relaunched for any update. However, we encourage all policies to support dynamic_refresh: true and per_profile: true whenever possible. This allows policies to be updated without restarting the browser, and it also allows policies to be applied to individual profiles instead of the entire browser instance.
  3. Features may be controlled by chrome://flags or a command-line switch. However, these methods are difficult for administrators who control thousands of devices. Most administrators prefer to use a dedicated management tool, such as Group Policy Editor or, to manage Chrome. These tools can set enterprise policies easily, but they cannot set feature flags.

A typical way to check a policy value together with a feature flag is to create a utility function that checks both. If the policy value conflicts with the feature flag setting, the policy value should always take precedence.

bool IsMyFeatureEnabled(Profile* profile) {
  return profile->GetPrefs()->GetBoolean(prefs::kMyFeature)
    && base::FeatureList::IsEnabled(features::kMyFeature);

Need more help?

Feel free to email with any questions.