Finがカスタマーサポートの重要な部分になるにつれて、変更管理はより複雑になります。コンテンツ、ガイダンス、手順、その他の設定が連携しているため、小さな更新でも予期しない影響を及ぼすことがあります。Releasesはこれらの変更を管理するための構造化された方法を提供します。

Releasesは専用の作業スペースでFinの設定変更を安全に準備・展開できるようにします。編集を直接ライブのFin設定に公開する代わりに、すべての変更はリリースに追加されます。

Releasesを使うと、次のことができます：

リリースは変更を保持します。変更を追加し、安全に編集し、不要になったものはリリースの一部として削除できます。ライブのFinには、公開または実験を開始するまで何も影響しません。

最初のリリースを作成するには、Fin AI Agent > ナビゲーション上部のドロップダウンから「Service」を選択し、その下のドロップダウンで「Fin Main」をクリックします。リリースを作成をクリックしてください。

説明的な名前と説明を付けてください。例えば「返金処理の変更」のように、何が変わるかを示すものです。説明は内部用で、リリースの内容を簡単に識別できます。

これでリリースに変更を追加できます。例えば、「Content」でヘルプ記事をテストし、「Guidance」や「Escalation Guidance」で行動ルールをテストし、「Procedure」で複数ステップのフローをテストします。

変更を追加すると、リリースの変更リストに表示されます。

アイテムをクリックして差分を表示すると、各アイテムで行われた正確な変更が簡単に確認できます。

リリース内でさらにアイテムを追加・編集・削除するには、リリース内で変更を追加をクリックします。リリース内で以下のアイテムタイプを操作できます。

リリースの概要にはすべてのアイテムがリストされているので、簡単に全体を把握し、必要に応じてさらに変更できます。

リリース概要の各アイテムには、変更の種類を示すインジケーターが付いています。

異なるReleasesに切り替えたい場合は、ページ左上のナビゲーションのスイッチャーを使ってください。そこから新しいReleasesを作成したり、ライブのFinの本番バージョンである「Main Fin」に切り替えたりできます。

ライブ会話に到達する前に、リリースをプレビューして、変更が適用されたFinの動作を正確に確認してください。

Previewは、Finがあなた自身で入力した1つの質問をどのように処理するかを教えます。Evalsは、保存されたテスト会話のセット全体をReleaseに対して実行し、それぞれに自動的に合格/不合格の結果を出すことができるため、変更がFinの他の動作を壊していないかを顧客に届く前に確認できます。

Evalは、テーマ別のSimulationのグループ（あなたが定義した基準を持つ現実的な複数ターンのテスト会話）です。Releaseに対して実行すると、すべてのSimulationがライブのFin Main構成ではなく、Releaseの変更が適用された状態で実行されます。ライブの会話には影響しません。

Evals、Simulations、およびスコアリングの詳細については、Fin Evals [beta]をご覧ください。

開始するには、テストしたいReleaseを開きます。Releaseの概要ページでEvalsセクションを見つけて、See Evalsをクリックします。

実行したいEvalを選択します。既に回帰テストスイートとして構築したものか、この変更のために新しく作成したもののいずれかです。

実行します。Eval内のすべてのSimulationがReleaseに対して実行され、合格/不合格の結果、完全な会話の記録、Finの思考を示すイベントログ、および各Simulationの結果が返されます。

失敗した箇所を確認し、Release内でさらに変更を加え、修正を確認するためにEvalを再実行します。

Releaseをライブに設定したり、ロールアウトを開始および終了するには、チームメンバーに「Can manage Automation settings and inbound Workflows」の権限が必要です。

変更がプレビューで問題なければ、どのように顧客に届けるかを決定します。

Releaseの概要ページでRollout releaseをクリックし、次の2つのオプションのいずれかを選択します：すぐにすべての顧客に公開するMerge to main、または段階的なロールアウトやA/Bテストを実施してから全員に展開するRoll out gradually。

Merge to mainは、変更をすぐにFin Mainに公開し、すべての関連する会話に適用します。変更に自信があり、すべての場所で有効にしたい場合に選択してください。

Roll out graduallyを選択すると、完全にコミットする前に会話の一部に対して変更をテストできます。2つのロールアウトタイプから選択してください：

Phased rolloutを選択した後、以下を設定します：

Start phased rolloutをクリックして開始します。ロールアウトはすぐに開始され、ReleaseのRolloutsタブのActive rolloutに表示されます。

ロールアウトが実行中の場合、ReleaseのRolloutsタブを開きます。実行中のロールアウトはActive rolloutに、完了したものはPast rolloutに表示されます。

こちらはphased rolloutの結果の例です。リリースによって影響を受けた会話を簡単に掘り下げて、Fin Mainの会話と比較してスポットチェックできます。

こちらはa/b test rolloutの結果の例です。以下が簡単に確認できます：

有意な結果：

結論が出ない結果：

後退する結果：

独自のカスタムレポートも作成できます。ReportsセクションでカスタムレポートにReleaseとExperimentのフィルターを追加して、実験のバリアント間のパフォーマンスを比較してください。

Releaseのロールアウトを顧客に影響させないように停止するには、ロールアウトを終了します。新しい会話はすぐに現在のライブ設定に戻ります。

リリースがFin Mainにマージされた後、そのリリース自体から変更をロールバックできます。

これは依然として各アイテムのバージョン履歴をFin Mainで使用しています。リリースは、変更されたすべてのアイテムに直接移動するだけで、ユーザーがそれぞれを探して開く必要はありません。

マージされたリリースから変更をロールバックするには:

Fin for Salesforceは複数のSalesforce組織に接続します。1つのワークスペースはライブ組織と1つ以上のテスト組織を保持できます。接続された各組織はenvironmentです。

すでにWorkflowsを1つの環境にスコープできます。Deployを開き、Salesforce casesなどのワークフローを開き、トリガーでEnvironmentを設定します。デフォルトはAll environmentsです。

そのピッカーはどのワークフローが実行されるかを制御します。内容、ガイダンス、またはFinが読み取る手順は変更しません。Finはすべての環境で同じライブ設定を読み取ります。

リリースは設定自体を変更します。リリースは1つの対象者のために各エンティティの異なるバージョンを固定します。エンティティは識別子を保持するため、コピーしません。1つの対象者と1つの割合がグループ全体を制御し、ロールバックできます。

Finは環境を各会話に書き込みます。環境はシステム定義の会話属性です。対象者ルールはこの属性を読み取れます。

リリースの展開は1つの対象者を取ります。展開は対象者に一致する会話にのみリリースを適用します。

Connectを開きます。Connect Fin to a test organizationで組織を見つけます。ステータスはConnectedでなければなりません。

Settingsを開きます。DataグループでAudiencesを選択します。

新しい対象者を作成します。環境名を含む名前を付けます。

Add audience ruleを選択します。Conversation dataグループでEnvironmentを選択します。

テストしたい環境を選択します。次にSaveを選択します。

リリースを開きます。Rollout releaseを選択します。次にRoll out graduallyを選択します。

タイプはPhased rolloutのままにします。

Audienceでステップ3の対象者を選択します。

Traffic splitでスライダーを100%に動かします。パネルには100% Release (treatment)と0% Main Fin (control)が表示されている必要があります。

Start phased rolloutを選択します。

テスト組織で新しい会話を開始します。Finはリリースの設定で応答します。

ライブ組織で会話を開始します。FinはFin Mainで応答します。