はじめに

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

発想の経緯

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

Formsを起点としてSharePointリストに項目を作成して一覧として管理、と同時に通知としてTeamsにメッセージを投稿する。というフロー、よくあると思います。

対応に漏れがないようにリスト管理するはずが、通知メッセージに返信の形でチームメンバーとコミュニケーションをとった結果、なんだかんだ解決→リストの更新を置き去りにしてしまう、ということがありました。

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

やりたかったこと

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

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

つくったもの

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

フローの簡単な解説

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

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

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

元のカードが消えてしまう問題に関しては以下のアクションを使って解決することができました。

しかしながら、1回しか更新できないという問題が解決できず、この方法は廃案としました。
(状況を都度更新したかったため、複数回更新する必要があった)

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

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