LoginSignup
7

posted at

updated at

チャネルのスレッドとSharePointリストを連携させる(概要編)

はじめに

この記事は①概要編 ②受付フロー編 ③更新フロー編 の3本立てのうち、①概要編です。
以降の記事でフローの細かい解説を予定していますが、待ちきれない方はこの記事の最終にサンプルフローを用意しておりますので、そちらからご確認ください。

発想の経緯

業務におけるありがちな問題点

Formsを起点としてSharePointリストに項目を作成して一覧として管理、と同時に通知としてTeamsにメッセージを投稿する。というフロー、よくあると思います。
image.png
対応に漏れがないようにリスト管理するはずが、通知メッセージに返信の形でチームメンバーとコミュニケーションをとった結果、なんだかんだ解決→リストの更新を置き去りにしてしまう、ということがありました。

漏れがないように一覧管理しているはずが、管理と通知が別の場所にあるため起こった問題です。
image.png

やりたかったこと

リストとチャネル、どちらか一方で管理とやり取りができればよいのですが、メンバーがチャネルでのやり取りに慣れていたため、今回はTeamsのチャネルからリストを更新する方法を考えました。

リストアイテムのコメントでメッセージをやり取りしてもよかったのですが、以前からの方法に合わせた形です。

つくったもの

ということで、作ったものがこちらです。

フローの簡単な解説

失敗例①「アダプティブ カードを投稿して応答を待機する」

image.png
初めに思いついたのがこのアクションを使う方法です。
このアクションでユーザーからの応答を取得し、その情報からリストを更新することは可能でしたが、次のような問題がありました。

  • 投稿からは1回しかリストを更新することができない。
  • 更新後(Action.Submit)に元のカードが消えてしまう。
  • フローの制限から長期的な案件が管理できない。(30日でタイムアウト)

元のカードが消えてしまう問題に関しては以下のアクションを使って解決することができました。
image.png
しかしながら、1回しか更新できないという問題が解決できず、この方法は廃案としました。
(状況を都度更新したかったため、複数回更新する必要があった)

失敗例②「誰かがアダプティブ カードに応答した場合」

image.png
次に考えたのはこのトリガーを利用する方法です。
このトリガーでは、投稿からの応答を何度でも取得することが可能です。
ただし、今回のケースでは問合せごとにチャネルに通知が投稿されるため、複数のカードが投稿されます。
どのカードから応答があったのか、そして「そのカードとセットになっているリストの項目がどれなのか」を直接特定する情報がトリガーのアウトプットにはなかったため、リストを更新することができませんでした。
image.png

解決策

アダプティブカードにテキストとしてリストのIDを記載することにしました。
「メッセージ詳細を取得する」アクションから、カードに記載したリストIDを抽出することで、関連するリストアイテムを特定しています。
image.png
image.png

フローをGithubに保存しました

この2つのフローはセットで動きます。
詳しい解説は次回行います。

今回は以上です。


Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
7