As Fin becomes a bigger part of your customer support, managing changes becomes more complex. Content, guidance, procedures, and other configuration all work together, which means even small updates can have unexpected effects. Releases give you a structured way to manage those changes.

Releases let you safely prepare and deploy changes to your Fin configuration in a dedicated workspace. Instead of publishing edits directly to your live Fin configuration, you can add changes to a release.

With Releases, you can:

A release holds the changes. You add items to it, edit them safely, and remove anything you no longer want live with Fin as part of that release. Nothing in a release touches Main Fin until you publish it or start a rollout.

Releases currently work with the Service agent only. To create a release:

Give the release a descriptive name that says what's changing, for example "Refund processing changes". The description is optional. The name and description are for your team only, to help you identify what's in the release, and Fin doesn't use them.

Once you create a release, you're working inside it. The app changes color and the release switcher at the top left shows the release's name, so you can tell you're not in Main Fin. Any change you save from here goes into the release, not Main Fin.

Now you can add changes to your release. For example, select Content to test a help article, Guidance or Escalation guidance to test behavioral rules, Procedures to test a multi-step flow, or Skills to test a skill.

Once you've added a change, it appears in your list of changes in the release. The release has Changes, Evals, and Results tabs, and each tab shows a count.

To see the exact changes made to an item, click the item and view its diff:

To add items to a release, open the release, click Add more changes, and choose the type of item. You can add, edit, and delete these item types in a release:

You can create a new item, such as a public article, directly inside a release. To create a new item in a release:

A new item shows Publishes with the release instead of Published, and this status is locked. The item goes live only when you publish the release or start a rollout. Unlike an item that already exists in Main Fin, a new item's audience menu is open, so you can change the audience inside the release.

After you save a new item, a confirmation message appears with a View changes button.

When you open an item that already exists in Main Fin, the editor is locked by default. To edit an existing item in a release:

After you save an existing item to a release, a confirmation message appears with a View changes button.

When an item already exists in Main Fin, its Published, Sales agent and Copilot availability, and Audience settings are locked inside a release, and a lock icon appears next to each one. An item that is already published on the Help Center can't be unpublished from a release. To unpublish an existing item or change its audience, switch to Main Fin and change it there. If the item is part of a release running a rollout or A/B test, Main Fin can't change it until that rollout or A/B test is stopped or the release is published.

You can also save an edit to a release while you're working on an item in Main Fin. To save an edit from Main Fin to a release:

An item that is part of a release shows a release badge with a count next to its title. Click the badge to see which releases include the item and whether it was edited.

Each item in the release overview has an indicator showing the type of change:

To switch to a different release, use the switcher at the top left of the navigation. You can also create new releases from there, or switch to Main Fin, which is your live production version of Fin. The switcher lists each release with its number of changes and its status, such as Draft or a rollout percentage. It also has a search box, Manage releases, and New release.

To go back to Main Fin from a release:

Once you're back in Main Fin, the app and your inboxes appear in grey, and any change you publish goes live straight away. When you're in a release, the app appears on a colored background instead.

Before anything reaches a live conversation, preview the release to see exactly how Fin behaves with your changes applied.

Evals let you run a whole set of saved test conversations against your release and get an automatic pass or fail result for each one, so you can check a change hasn't broken Fin's behavior elsewhere before it reaches customers.

An Eval is a themed group of Simulations (realistic, multi-turn test conversations with criteria you define). When you run one against a release, every simulation runs with your release's changes applied instead of Main Fin. Nothing touches live conversations.

To learn more about how evals, simulations, and scoring work, see Fin Evals.

To work with releases, a teammate needs the propose level or the publish level for each kind of change in the release. Permissions for Fin AI Agent & Automation, Knowledge content, and Help Center articles each have levels, and each level includes everything below it.

For releases, 2 levels matter:

To set a release live, you need the publish level for every kind of change in it. For example, if a release includes guidance and a Help Center article, you need the publish level for both Fin AI Agent & Automation and Help Center articles.

This table shows the exact permission option for each level in each permission area:

The Fin AI Agent & Automation permission covers all automations configuration:

It also covers all Fin AI Agent configuration:

Knowledge content permissions cover snippets, internal articles, and web syncs.

Help Center articles permissions cover viewing, proposing, and publishing Help Center articles. The permission card also has a separate option, Can manage saved views for Help Center articles.

A teammate who can only view configuration or content can open Fin settings, simulations, and evals, but can't change them.

If an item in your release is changed in Main Fin after you added it, the release detects a conflict. This can happen with any item type. For example, a teammate might publish an update to the same guidance directly in Main Fin, or publish another release that edits it.

While there's a conflict, you can't publish the release or start a rollout until you fix it.

To fix a conflict:

When your changes preview well, you decide how they reach customers. Open the release and choose how to ship it:

To learn more about publishing, rolling out gradually, and A/B testing a release, see How to roll out a release in Fin.

You can end a rollout at any time, or roll back items from a published release using each item's version history. To learn how, see How to roll out a release in Fin.

These articles cover related tasks for releases and testing Fin changes: