Setting up Reviews for Team Workflows

You can enable reviews for all Statsig resources such as feature gates, dynamic configs, segments, and experiments that you’ll likely deploy to a production environment.

Turning on Change Reviews for a Project

As a Project Admin, you can configure your project to require reviews for any changes. To enable reviews for your project, navigate to the Project Settings page, switch to the Reviews tab and toggle this on.

• You can optionally allow different roles to bypass the review requirement and self-approve review requests by customizing the permissions available to user roles:

• Now when you make any configuration changes, say to a feature gate or experiment, you’ll be asked to Submit for Review; you can add reviewers when you submit the change for review

• Reviewers will now see a notification on the Statsig console as shown below. When they click on View Proposed Changes, they will see a diff of the current version in production and new version. Reviewers can now Approve or Reject the submitted changes.

Teams

To create a predefined group of reviewers, you can create Teams

You can now use these predefined Teams when you submit any changes for review.

Enforcing Team Reviews

You can a priori restrict who can make changes to your Project by (a) turning on Reviews Required for your Project and (b) adding designated Teams or Reviewers when you create the Feature Gate or Experiment.

For (a), see section Turning on Change Reviews for a Project to turn on project-wide reviews. For (b), as an owner of a Feature Gate or Experiment, you can add designated Teams or Reviewers at any time as shown below. This ensures that only these designated groups or members can review and approve any subsequent changes. When another member now tries to edit these designated review groups/reviewers, this will require approval from currently designated reviewers.

Configuring Review Settings for Different Environments

Many teams build, test, and launch new features and experiments across multiple development environments. Statsig makes creating and using environments in feature launches easy via our Environments support.

You can also configure which environments require reviews via your Project Settings. To do so, go to Project Settings —> Keys & Environments —> tap Edit on Environments.

By default if you have turned on “Reviews Required” for your Project, reviews will be required for Production, but not non-Production (lower) environments.

Configuring Custom Approval Workflows (Pre-commit Webhooks)

If you prefer to leverage an internal approvals workflow or, for example, want to run proposed config changes through a suite of automated tests before they go live, you can leverage Pre-commit Webhooks. Pre-commit Webhooks enable you to listen for config changes on the Statsig side, route those changes through internal approval processes, test suites, etc. and then leverage Console API to send back either a review approval or rejection before final changes can be committed.

To enable the Pre-commit Webhook experience:

1. Integrate your approval flow with the change validations Console API, see documentation here.
2. Configure the experience for Statsig Console users via Settings -> Product Configuration -> General, where you will be able to configure the “Pending State” banner text, URL, and a Pre-commit Webhook key for verification purposes.

Now, when a change is made in the Statsig Console, Statsig hits the customer’s configured webhook with the proposed changes. The change in Statsig will be pending until the customer approves the review via Console API (after their internal checks are complete). Statsig exposes an option for Project Admins (only) to bypass this process and commit the changes directly.

Every payload will have these fields at a minimum:

review_id (will need to pass this to the change_validation API to accept/reject a change)
submitter (email address)
committer (email address)
config_type (one of gate, dynamic_config, segment, or experiment)
type (listed below)
config_name / experiment_name

Currently, only changes to gates, dynamic configs, segments, and experiments trigger precommit webhooks, and only the following changes:

• rules: Updating rules (for gates, dynamic configs, segments)
  • will contain payloads old_config and new_config with the same format returned by the console API for the entity type (e.g. https://docs.statsig.com/api-reference/gates/read-gate for gates)
• update_target_apps: Updating target applications
• update_allocation: Changing the pass percentage of an ongoing experiment
• start_experiment
• ship_experiment
• abandon_experiment
• update_experiment_settings: Changing settings of an ongoing experiment
  • will contain payloads old_experiment and new_experiment with the same format returned by the console API (https://docs.statsig.com/api-reference/experiments/get-experiment)