公開 2026年10月28日

ZendeskからSlackへ通知する｜担当者への連絡と結果記録

実現すること

特定の条件に合うチケットが作成された時に、担当チームのSlackチャンネルへ連絡し、通知した結果をチケットに残す構成を考えます。Slackの会話をZendeskへ常時同期する構成とは用途が異なります。

緊急の問い合わせを見つけた人が、チケットURLと要点をSlackへ貼り付けていると、連絡漏れや、誰が通知したか分からない状態が生まれます。通知対象と投稿内容を揃え、連絡後の確認先をチケットへ集めます。

構成例

Zendeskのアクションフローと、Slackワークスペースへの接続を使います。基本フローの利用可否は契約と管理画面で判断します。Slack側ではアプリの承認権限、投稿先へのアクセス、Zendesk Connectorアプリのチャンネルへの招待が必要です。

外部操作は接続したアカウントに帰属します。個人の異動や退職で連携が止まらないよう、管理するアカウントと引き継ぎ方法を決めます。接続は各外部システムにつき1インスタンスという制限があるため、複数ワークスペースを一つの標準接続で使える前提にしません。

チャンネルへの投稿は標準コネクタの機能です。一方、Slackの新規投稿などを開始イベントにする機能は、現行リファレンスではEAPとして案内されています。本記事はZendeskのチケットを開始点とします。

公式のSlack通知レシピと機能一覧に基づく手順です。ここでは「特定窓口の緊急チケット作成」を対象にした構成例を示します。

テスト用のチケットとSlackチャンネルを用意し、通知する項目を決めます。件名、優先度、チケットURLなどに絞り、本文全文や個人情報の自動転記は避けます。
管理センターでフローを作成し、チケット作成イベントに対象の条件を設定します。優先度の比較値は表示名ではなく、リファレンスで示される値を使います。たとえば緊急は urgent です。
必要に応じてチケット情報の取得ステップを置きます。開始イベントのチケットIDを渡し、通知に必要な項目を取得します。
Slackのコネクタを接続し、チャンネル投稿のアクションを追加します。投稿先とメッセージに固定値・前段の変数を割り当てます。認証はSlack側の案内と管理者の承認方針に従います。
投稿の出力にあるチャンネル、投稿時刻の識別値、成功フラグを確認し、成功時にチケットへ内部メモを追加します。通知を試みただけで「送信済み」と記録しないようにします。
専用チャンネルで、対象・対象外、投稿先にアクセスできない場合を試します。投稿内容とチケットの記録を照合し、保存・有効化後の実行ログを確認する担当を決めます。

テストは外部へ実際に投稿し得ます。クレジットを消費しないことと、外部への影響がないことは別です。

通知を送るだけでは、Slack側で担当者が読んだ・対応したことまでは分かりません。対応状況はZendeskの担当者やステータスで管理し、Slackの投稿成功を対応完了として扱わないようにします。

チケット更新を開始点に拡張する場合は、フローの内部メモ追加による再更新も含め、再通知条件を設計します。処理済み記録の確認と、失敗時に再実行する範囲を決めます。同時実行や再試行を含む「必ず1回だけ」の通知は、この構成だけでは保証しません。

Slackへの投稿はアクションクレジットの主な消費対象です。対象件数と投稿回数を減らすには、通知する窓口・重要度を明確にします。

条件に合うチケットをSlackへ投稿し、結果をZendeskへ記録する部分は標準機能を組み合わせる範囲です。Slack Connectでの受付、会話・添付の継続同期、複数ワークスペースへの配信、厳密な重複抑止は、別の連携設計や開発を検討します。

Slackからの起票も含めて方式を選ぶ場合は、標準連携と独自開発の違いを参照してください。Slackの問い合わせをZendeskで起票・管理する支援では、受付から担当者への引き継ぎまで相談できます。

対象業務に合わせて、標準機能とAPI連携・追加開発の範囲を整理します。