トリガーの概要

新しいトリガー "When someone responds to an adaptive card"では、Teamsに投稿したAdaptive Cardの入力フォームからのデータ送信をきっかけとしてフローの実行が可能になります。

ユーザーの入力を受け付ける場合、これまでは "Post adaptive card and wait for response" を利用していましたが、新しいトリガーとユーザー入力を待たないPost adaptive card のアクションを組み合わせることでも、Adaptive cardを利用したユーザーとのインタラクションが可能になりました。

この新しいデザインパターンは、カード送信部分と入力受信後の処理を独立してメンテナンスできるだけでなく、後述するように、これまで困難であった/標準アクションでは対応できなかったようなシナリオを実現可能にします。

今回の投稿ではトリガーの詳細と、活用パターン、そして制限事項について紹介します。

トリガーの詳細

新しいトリガー"When someone responds to an adaptive card"では2つの入力パラメータが必要になります。ここではそれぞれのパラメータの詳細とトリガーの動作について紹介します。

入力パラメータ : Inputs Adaptive Card

1つ目のパラメータ Inputs Adaptive Cardは、ユーザーが入力を行うAdaptive cardの定義 (JSON) を指定する部分です。

このパラメータはカードの入力結果を解析して、後続のステップで利用する動的コンテンツを生成するために使われます。(JSONの解析アクションでサンプルのJSONを指定するようなもの)

面白いことに、送信されたカードのJSONと Inputs Adaptive Cardで指定したJSONが異なっている場合でもトリガーは失敗しません。

もしここで定義されている入力パーツ以外を追加した場合には、自力で(数式を利用して)データにアクセスする必要があります。 (triggerBody()?['entity']?['cardOutputs']?['入力パーツのID']という形式)

入力パラメータ : Card Type Id

今回のトリガーで重要なのがこの Card Type Id というパラメータです。このパラメータを通じて、送信したカードと"When someone..."のトリガーが関係づけられます。

カードを送信するアクション "Post adaptive card in a chat or channel" では、よく見るとadvanced optionとして Card Type ID という値を指定できることに気付きます。

まさにこの送信アクションのCard Type ID とトリガー側の Card Type Id をそろえることで、入力を受け付けられるわけです。

送信側のCard Type IDとトリガーのCard Type Idをそろえることで発火する

動作

実際に動作を確認してみると、送信したAdaptive cardのCard Type IDと同一の設定を持つフローが、ユーザーのデータ送信で即時実行されていることが分かります。 (このトリガーはポーリングではなくあくまでもインスタントトリガー)

また、データ送信時にカードが更新されるということはありません。ずっと入力欄が表示されたままです。

このため、1つのカードで複数回ユーザーの入力を受け付け、別フローでその入力を使って処理することが可能になります。

これまでの応答を待つアクションではユーザーが入力を行った後、フローが応答を受け取って先に進んでしまうため1カードで1応答しか受け付けられませんでしたが、今回のトリガーを使うことで、1カードで複数ユーザーの応答を受け付けることができるわけです。

例えばチームのチャネルにカードを送った場合、チーム内の誰かが入力を行うとほかのユーザーの入力はエラーではねられていました。（早い者勝ち）しかし、新しい組み合わせではチームメンバー全員の入力をチャネルに送られた1つのカードで受け付けることができます。

これは全く新しいAdaptive cardを利用したフローの設計パターンを提供してくれるものです！

もう一つ面白いことに、Card type Idをそろえた複数のフローを用意した場合、そのどれもが実行されていることもわかります。今までのアクションではユーザーの応答を受け取って複数の処理を直列/並列に実行させていましたが、新しいトリガーではフロー単位で複数の処理を用意することができます。（例えばフローAで送信して、フローBで受信データをリストに登録、フローCで入力結果をもとに入力を行ったユーザーにメッセージを送るなど、必要に応じて処理の追加ができる）

活用例

Adaptive cardで100ユーザーから入力を受け付けたいというケースを考えましょう。

これまでの応答を待機するアクションでは、ループ処理の中に"Post adaptive card... wait for response"とデータの登録処理をいれていました。この時、それぞれのループは回答が得られるまで完了しないので、ユーザーの応答が得られないとずっと次のループに進まないという問題がありました。つまり後半の人になるほどいつになってもカードが送られてこないという事態が起きるわけです。

今回のトリガーでは、応答を待機しないアクションを利用するため、ユーザーの応答を待たずに次のループが実行されます。ですので、カード送信にかかる時間x100回でループ処理は完了するわけです。（後半の人になってもほとんど同時刻にカードを受け取れる）

1日のうちにユーザーの入力を収集し終えたいようなケースでは特に有効ですね。

また、カードが更新されないので、使いまわしもできます。例えば日々の健康チェックをAdaptive cardで行っている場合、1つのカードに毎日入力してもらえば、毎日毎日送信用のフローを実行する必要はありません。

このように、これまで困難だった、あるいは実現不可能だったようなシナリオにもAdaptive cardを利用することができるようになります。