実行JSMからSlackの接続性が確保できると設定画面は以下のように変化して、次に、Slackと連携するJSMプロジェクト内のリクエストタイプを選択します。今回の検証では、タイプ別、承認の有無で動作確認をしたいため、以下のリクエストタイプを選択しました。problemに含まれるカスタムフィールド(追加項目)の1つが連携サポート対象外と警告が出ていますが、検証ですので、そのまま処理を続行します。連携する先のSlackチャンネルはすでに前段で作成してありますので、このままOKで先に進めます。すると、Slack側でAssistボットからメッセージを送ったので、そちらからセットアップを続けるように案内メッセージが表示されますが、再度OKで一度、JSM側での設定を完了とします。Slack側の設定JSMとの中継を担うAssistボットより、DMが届いており、そこには、「トリアージ用に作成したプライベートチャンネルからAssistボットを追加して指示に従うように」と書かれていました。channelをクリックします。どの「キュー」=「JSMのプロジェクト」と連携するか選択肢が出てきましたので、新設したJSMのプロジェクトを選択します。「キュー」は、Halpを利用する場合にも出てきますが、仕様(仕組み)を理解する上で重要な概念になります。queueという選択肢があるのは、少々気になりますが、無視してよい選択肢と思われますので、ココではスルーします。移動して同様の設定を行います。問い合わせに応答するエージェントのメンバーをトリアージチャンネルに招待するといった付随操作も必要ですが、動作検証時には必要ありませんので、今回は割愛します。設定が完了すると、トリアージチャンネルとの連携ができた旨の案内メッセージが表示されます。Chatの設定画面をリロード、あるいは、画面内のOKをクリックすると連携したSlackチャンネルの情報が表示されます。連携しているリクエストタイプの一覧を見ることができます。詳細な設定については、ドキュメントを参照してください。サポート絵文字の設定では、初期設置として以下が設定されています。shortcutより、絵文字によるアクションの追加が可能で、アクションを実行する絵文字スタンプの選択した後に、設定できることは以下の2点となります。今後、このあたりは実際の運用の中でカスタマイズをしていきたいと思います。Chatの場合でも機能するかを確認します。細かな検証過程は省きまして、結論を書きますと「7」の承認以外は全て想定通りに操作ができました。Chatに置き換えたとしても問題なく利用継続できると評価しています。検証時の気づき自動のチケット作成(Slackフォーム表示)の追加設定リクエストチャンネルにメッセージを投稿した際に、自動的にチケットが作成されるようにするためには、JSM側の追加設定が必要で、以下のように、対象のリクエストチャンネルの設定編集にて、自動起票を有効化する必要がありました。いうボタンが出現し、そちらを実行すると作成するチケットのリクエストタイプを選択する画面が表示され、選択したタイプに応じたSlackフォームに遷移します。Slackで承認するための追加設定チケットに承認工程がある場合に、その承認のアクションをSlack上から実行できるとありましたが、そのためには、JSM側で追加の設定が必要です。承認に関しては、こちらの設定を行ってもSlack側、Assistボットを通じて、認証の通知や、認証のアクションを取ることができませんでした。サポート既定では、チャットでのリクエストの承認は有効になっています。対応することができます。承認の詳細をご確認ください。既定ではSlack上での承認が有効とありますが、今回の動作検証時は、既定が「無効」になっていましたので、何か設定の不備などがあるかもしれません。本件につきましては、別途、調査をして問題解消したいと思います。Chatへの移行については、全く問題ないと評価しています。Chatへの移行検討につきましては、以下のエントリーにまとめていますので、あわせて、ご参照ください。EC2のデプロイを方法別で比較。