Zendeskトリガーをアカウント間でエクスポートおよびインポートする方法

Zendesk（ゼンデスク）のトリガーをあるアカウントから別のアカウントに移動することは、単純に聞こえますが、すぐに複雑になる一般的なタスクです。買収後にアカウントを統合する場合でも、サンドボックスから本番環境に移行する場合でも、新しいインスタンスをセットアップする場合でも、自動化ルールを壊さずに転送する信頼性の高い方法が必要になります。

簡単な説明：Zendeskには、トリガーの組み込みのエクスポート/インポート機能はありません。主なオプションは2つあります。APIメソッドは、完全な制御を提供しますが、技術的な専門知識が必要です。サードパーティの移行ツールは、複雑さを処理しますが、価格が伴います。

このガイドでは、両方のアプローチについて説明し、一般的な落とし穴を説明し、移行中にワークフローを中断しないようにする方法を示します。

複雑なトリガー設定の管理が負担になっている場合は、最新の代替手段を検討することをお勧めします。eesel AIは、多数のトリガールールを維持することに依存しない、サポート自動化への異なるアプローチを提供します。

Zendeskトリガーを移行する必要がある理由

方法に入る前に、トリガーの移行が必要になる一般的なシナリオを見てみましょう。

サンドボックスから本番環境へ：サンドボックス環境でトリガー設定を完成させるのに数週間費やしました。手動で再作成せずに、これらの慎重に作成された自動化をライブアカウントに移動する必要があります。

アカウントの統合：あなたの会社は別のビジネスを買収するか、部門を合併しました。両方のチームに、確立されたトリガーワークフローを備えたZendeskアカウントがあります。それらを単一のアカウントに結合する必要があります。

マルチブランド設定：サポート構造を再編成しており、特定のブランドトリガーを専用アカウントに移動する必要があります。

テストとロールバック：トリガーの変更を試したいが、問題が発生した場合にすばやく元に戻す方法が必要です。

注意点：トリガーはアカウント間で簡単にコピーできません。各トリガーには、アカウントに結び付けられた一意のIDがあります。グループ、カスタムフィールド、スケジュールなどの依存関係は、IDで他のオブジェクトを参照します。新しいアカウントに移動すると、これらのIDは存在しません。「VIPサポートグループに割り当てる」トリガーは、ターゲットアカウントにまったく同じIDを持つグループが存在しない場合、機能しません。

これが、直接コピーアンドペーストのアプローチが失敗する理由です。これらの参照を変換するか、最初に依存関係を再作成する方法が必要です。

開始する前に必要なもの

トリガーの移行を成功させるための前提条件を分解してみましょう。

管理者アクセス：ソースとターゲットのZendeskアカウントの両方で、管理者権限が必要になります。トリガーの管理には、完全な管理者権限が必要です。

APIトークン：APIメソッドの場合、両方のアカウントでAPIトークンを生成します。[管理センター] > [アプリとインテグレーション] > [API] > [Zendesk API]に移動します。各アカウントのトークンを作成し、安全に保管してください。

依存関係のインベントリ：トリガーに触れる前に、トリガーが何に依存しているかを文書化します。次のリストを作成します。

• 割り当てアクションでトリガーが参照するグループ
• トリガー条件で使用されるカスタムチケットフィールド
• 営業時間条件で言及されているスケジュール
• トリガーが適用されるチケットフォーム
• トリガーがチケットを割り当てるエージェント

ターゲット環境の準備：トリガーをインポートする前に、一致するグループ、フィールド、およびスケジュールでターゲットアカウントを設定します。これは交渉の余地はありません。「Tier 2サポート」にチケットを割り当てるトリガーは、そのグループが存在しない場合、失敗します。

テスト計画：最初にテストするいくつかの重要でないトリガーを特定します。最も複雑な自動化から始めないでください。

方法1：Zendesk APIを使用してトリガーをエクスポートおよびインポートする

APIメソッドを使用すると、移行プロセスを完全に制御できます。これは、複雑な設定に最も信頼できるアプローチですが、ある程度の技術的な知識が必要です。完全なエンドポイントの詳細については、ZendeskトリガーAPIドキュメントを参照してください。

ステップ1：ソースアカウントからトリガーをエクスポートする

まず、ソースアカウント内のすべてのトリガーを一覧表示します。GET /api/v2/triggersエンドポイントを使用します。

curl https://{subdomain}.zendesk.com/api/v2/triggers \
  -v -u {email_address}/token:{api_token}

APIは、すべてのトリガーを含むJSONオブジェクトを返します。各トリガーには、条件、アクション、位置、およびアクティブステータスが含まれています。

多数のトリガーがあるアカウントの場合、ページネーションを処理する必要があります。APIは、ページあたり最大100件のレコードを返します。大規模なデータセットには、カーソルページネーションを使用します。

curl https://{subdomain}.zendesk.com/api/v2/triggers?page[size]=100 \
  -v -u {email_address}/token:{api_token}

完全なJSON応答をファイルに保存します。次のステップのためにこのデータが必要になります。

プロのヒント：sideloadパラメーターを含めて、使用状況の統計を取得します。これは、実際にアクティブで移行する価値のあるトリガーを特定するのに役立ちます。

curl https://{subdomain}.zendesk.com/api/v2/triggers?include=usage_30d \
  -v -u {email_address}/token:{api_token}

ステップ2：トリガーデータをマッピングして準備する

これは、ほとんどの移行が失敗する場所です。ソースアカウントからターゲットアカウントに一致するようにIDを変換する必要があります。

まず、トリガーJSON内のすべてのID参照を特定します。次のフィールドを探します。

• 割り当てアクションのgroup_id値
• エージェント割り当てアクションのassignee_id値
• トリガー条件のcustom_fields_参照
• 営業時間条件のschedule_id値
• フォーム固有の条件のticket_form_id値

ソースIDをターゲットIDに変換するマッピングドキュメントを作成します。例：

ソースID	ソース名	ターゲットID	ターゲット名
20455932	Tier 1 Support	98765432	Tier 1 Support
20455933	VIP Customers	98765433	VIP Customers

対応するグループ、フィールド、およびスケジュールを最初にターゲットアカウントに作成し、新しいIDをメモすることで、ターゲットIDを手動で検索する必要があります。

トリガーJSONを変更して、ソースIDをターゲットIDに置き換えます。各トリガーオブジェクトからidフィールドとurlフィールドを削除します（これらはターゲットアカウントによって割り当てられます）。実行順序を維持する場合はpositionを保持するか、ターゲットアカウントの既存のトリガーに合わせて調整します。

ステップ3：ターゲットアカウントにトリガーをインポートする

JSONを準備したら、POST /api/v2/triggersを使用してターゲットアカウントにトリガーを作成します。

curl -u {email_address}/token:{api_token} \
  https://{target_subdomain}.zendesk.com/api/v2/triggers \
  -H "Content-Type: application/json" -X POST \
  -d '{"trigger": {"title": "トリガー名", "conditions": {...}, "actions": {...}}}'

重要：最初は非アクティブな状態でトリガーを作成します。JSONで"active": falseを設定します。これにより、インポートプロセス中にトリガーが起動するのを防ぎ、チームに通知がスパムされる可能性があります。

各トリガーを作成した後、ターゲットアカウントによって割り当てられた新しいIDをメモします。これは、位置管理に必要になります。

一括位置更新には、PUT /api/v2/triggers/update_manyエンドポイントを使用します。

curl https://{target_subdomain}.zendesk.com/api/v2/triggers/update_many \
  -v -u {email_address}/token:{api_token} \
  -H "Content-Type: application/json" \
  -X PUT \
  -d '{"triggers": [{"id": 25, "position": 3}, {"id": 26, "position": 5}]}'

ステップ4：インポートされたトリガーを検証してテストする

インポートされたトリガーをアクティブ化する前に、正しく動作することを確認してください。

ターゲットアカウントでトリガーの実行順序を確認します。[管理センター] > [オブジェクトとルール] > [ビジネスルール] > [トリガー]に移動します。リストを確認して、位置が正しいことを確認します。トリガーの順序の管理の詳細については、Zendeskのトリガーに関するドキュメントを参照してください。

サンプルチケットで各トリガーをテストします。トリガー条件に一致するテストチケットを作成し、予期されるアクションが発生することを確認します。

トリガーがメールを送信する場合は、通知の配信を確認します。適切な人が通知を受信し、テンプレートが正しくレンダリングされることを確認します。

検証後にのみトリガーをアクティブ化します。update_manyエンドポイントを使用して一括でアクティブ化します。

curl https://{target_subdomain}.zendesk.com/api/v2/triggers/update_many \
  -v -u {email_address}/token:{api_token} \
  -H "Content-Type: application/json" \
  -X PUT \
  -d '{"triggers": [{"id": 25, "active": true}, {"id": 26, "active": true}]}'

方法2：サードパーティの移行ツールを使用する

APIメソッドが圧倒的に聞こえる場合は、サードパーティのツールがより簡単な代替手段を提供します。技術的な複雑さを処理しますが、コストがかかります。

Help Desk Migration

Help Desk Migrationは、プラットフォーム間でサポートデータを移動するための専門サービスです。ZendeskからZendeskへの移行を含む90以上のヘルプデスクシステムをサポートしています。

彼らのMigration Wizardは、ノーコードインターフェイスを提供します。ソースアカウントとターゲットアカウントを接続し、移行するものを選択すると、残りは彼らが処理します。特にトリガーの移行については、ID変換を処理しながら、Zendeskアカウント間でビジネスルールを転送できます。

主な機能：

• 無制限の無料デモ移行（20件のレコードでテスト）
• 移行中のダウンタイムゼロ
• 最初の転送後にレコードを更新するためのデルタ移行
• パッケージに応じて9/5から16/5のサポート

価格は、定額料金ではなく、レコードごとです。例として、1,000件のレコードの移行には約100ドルかかる可能性があり、10,000件のレコードには約514ドルかかる可能性があります。他の場所でより低い見積もりを見つけた場合は、価格一致保証を提供します。

パッケージ	サポート	SLA応答	データ保持
標準	9/5	24時間	3日間
プレミアム	16/5 + 週末	8時間	5日間
シグネチャー	16/5 + 週末	4時間	10日間

出典：https://help-desk-migration.com/pricing/

Import2

Import2は、ビジネスアプリ間で1クリックのデータ移行を提供します。Zendeskを含む50以上のプラットフォームをサポートしています。

彼らのアプローチは完全に自動化されています。アプリを接続し、無料のサンプル移行を実行して結果をプレビューし、満足したら完全な転送に進みます。

ヘルプデスクの移行の場合、価格は段階的です。

プラン	レコード制限	価格
ベーシック	1,000未満	$99
プラス	5,000未満	$199
プレミアム	50,000未満	$299
エンタープライズ	500,000未満	$499+

出典：https://www.import2.com/pricing

Import2は、返金保証とSOC 2 Type II認証を提供しています。広範なカスタマイズを必要としない、より単純な移行に適しています。

どのアプローチを選択するか

APIメソッドを使用する場合：

• チームに、移行スクリプトを作成および保守するための技術的なリソースがある場合
• 移行プロセスのあらゆる側面を完全に制御する必要がある場合
• カスタム処理が必要な複雑なトリガーの依存関係を管理している場合
• サードパーティのサービスコストを回避したい場合

移行ツールを使用する場合：

• チームに、APIを直接操作するための技術的な専門知識がない場合
• トリガーだけでなく、チケット、ユーザー、ナレッジベースの記事など、より多くのものを移行する必要がある場合
• 移行全体を通して専用のサポートを備えた管理プロセスが必要な場合
• ツールのコストが、節約できる時間と労力によって正当化される場合

トリガーの依存関係の管理

トリガーの移行における最大の課題は、トリガー自体ではありません。それは彼らが参照するすべてです。

確認する重要な依存関係

グループ：ほとんどのトリガーは、チケットを特定のグループに割り当てます。トリガーをインポートする前に、ターゲットアカウントに一致するグループを作成します。新しいグループIDをメモし、それに応じてトリガーJSONを更新します。

カスタムチケットフィールド：トリガーは、条件でカスタムフィールドの値を確認することがよくあります。最初にこれらのフィールドをターゲットアカウントに作成します。フィールドIDはアカウント間で異なるため、注意してマッピングする必要があります。

スケジュール：営業時間条件は、ターゲットアカウントに存在する必要があるスケジュールを参照します。ターゲットアカウントでスケジュールを再作成し、新しいスケジュールIDでトリガー参照を更新します。

チケットフォーム：一部のトリガーは、特定のフォームにのみ適用されるか、フォーム関連の条件を確認します。依存トリガーをインポートする前に、これらのフォームがターゲットアカウントに存在することを確認してください。

エージェント：割り当てアクションは、エージェントユーザーIDを参照します。最初にターゲットシステムにエージェントアカウントを作成し、古いIDをトリガーJSONの新しいIDにマッピングします。

トリガーJSONで依存関係を識別する方法

各トリガーのconditions配列とactions配列を確認します。次のフィールドタイプを探します。

{
  "conditions": {
    "all": [
      {"field": "group_id", "operator": "is", "value": "20455932"}
    ]
  },
  "actions": [
    {"field": "assignee_id", "value": "296220096"}
  ]
}

条件またはアクションの数値は、別のオブジェクトを参照している可能性があります。移行前に、これらの参照をすべて文書化します。

移行後の破損した参照の処理

慎重に準備しても、一部の参照が破損する可能性があります。それらを処理する方法は次のとおりです。

検証エラー：無効な参照が原因でトリガーの作成に失敗した場合、APIは詳細を含む422エラーを返します。参照を修正して再試行してください。

サイレント障害：一部のトリガーは正常にインポートされる可能性がありますが、実行に失敗する可能性があります。移行後、ターゲットアカウントのトリガーアクティビティを監視します。

依存関係の欠落：移行後にグループまたはフィールドの欠落を発見した場合は、ターゲットアカウントにそれらを作成し、IDをメモして、影響を受けるトリガーを更新します。

一般的な問題とトラブルシューティング

APIレート制限

Zendeskは、ほとんどのエンドポイントでAPIリクエストを10分あたり700に制限しています。多数のトリガーをインポートする場合は、この制限に達する可能性があります。

解決策：リクエスト間に遅延を追加します。トリガーをバッチで処理し、429応答を受信したときに指数バックオフを実装します。

トリガー位置の競合

ターゲットアカウントには、使用する位置を占有するトリガーがすでに存在する可能性があります。

解決策：インポートされたトリガーを使用可能な位置を使用するように調整するか、並べ替えエンドポイントを使用してインポート後にすべてのトリガーを再編成します。

移行中の通知スパム

アクティブな状態でトリガーをインポートすると、既存のチケットですぐに起動を開始する可能性があります。

解決策：常にトリガーを非アクティブとしてインポートします。検証後にのみアクティブ化します。また、移行中はターゲットアカウントでメール通知を一時的に無効にすることを検討してください。

ID不一致エラー

最も一般的なエラーは、ターゲットアカウントに存在しないIDを参照することです。

解決策：詳細なマッピングドキュメントを維持します。インポートを試みる前に、すべてのIDがターゲットアカウントに存在することを確認します。

検証の失敗

Zendeskは、トリガーの条件とアクションを検証します。無効な組み合わせは拒否されます。

解決策：ターゲットアカウントのトリガー定義エンドポイント（GET /api/v2/triggers/definitions）に対して各トリガーJSONをテストして、条件とアクションが有効であることを確認します。

トリガー移行のベストプラクティス

常に最初にサンドボックスでテストする：ターゲットアカウントにサンドボックスがある場合は、そこで移行を練習します。本番環境に触れる前に、問題を解決してください。

トリガーロジックを文書化する：移行前に、トリガーをエクスポートし、元のJSONを保存します。問題が発生した場合に、復元するための参照ポイントがあります。

移行中に通知を無効にする：トリガーをインポートする前に、ターゲットアカウントでエージェントのメール通知をオフにします。これにより、インポートプロセス中にトリガーが予期せず起動した場合のスパムを防ぎます。

ロールバック計画を維持する：移行を検証するまで、ソースアカウントを運用状態に保ちます。新しい設定が正しく動作することを確認するまで、ソーストリガーを削除または変更しないでください。

最新の代替手段を検討する：複雑なトリガー設定は、時間の経過とともに維持が困難になる可能性があります。トリガーの移行に多大な労力を費やしている場合は、現在の自動化アプローチがまだニーズに対応しているかどうかを評価する価値があるかもしれません。最新のAI搭載サポートツールは、構成のオーバーヘッドを減らして、多くの自動化シナリオを処理できます。

eesel AIでサポート自動化を合理化する

複雑なトリガーワークフローの管理には、多大な時間と専門知識が必要です。Zendeskトリガーの移行、デバッグ、および保守に何時間も費やしている場合は、より良い方法があるかもしれません。

eesel AIは、従来のトリガーベースの自動化と並行して機能するか、置き換えることができる、カスタマーサポート向けのAIチームメイトです。さまざまなシナリオを処理するために多数のルールを作成する代わりに、過去のチケットとドキュメントでeesel AIをトレーニングします。ビジネスロジックを自然に学習し、チケットを自律的に処理します。

トリガーベースの自動化との違いは次のとおりです。

• 複雑なルールメンテナンスは不要：eesel AIは、すべてのシナリオに明示的なルールを必要とするのではなく、データから学習します。
• 自然言語の指示：条件とアクションを構成する代わりに、何をするかを平易な英語でeeselに指示します。
• 段階的なロールアウト：レビューのためにeeselが返信を下書きすることから始め、それが証明されるにつれて完全な自律性にレベルアップします。
• Zendeskと連携：eesel AIはZendeskと直接統合されているため、AI機能を追加しながら既存の設定を維持できます。

現在の設定が扱いにくくなったために、大規模なトリガー移行を検討している場合は、AI搭載のアプローチがサポート業務を簡素化できるかどうかを検討する価値があるかもしれません。