FormsとPower Automateで利用条件への同意フォームのようなものを作る

はじめに

Formsの複数チェックボックスを使って、利用条件への同意フォームのようなものを作る事があります。

これをPower Automateと連携させ、すべての項目に同意した人には利用案内を、そうでない人には確認項目の再確認を行う、という仕組みを用意するとします。

この時、Formsの複数チェックボックスで入れられた値の扱いにやや注意が必要になります。そのポイントをまとめてみました。

Formsの用意

例えば、テックブログ利用申請時に、次のような項目に同意が必要だったとします。

  • 運用ルール・ガイドラインを確認し、同意しました
  • アカウント作成・利用ルールについて確認、同意しました
  • 記事の作成、公開ルールについて確認、同意しました
  • その他、記事内容に関するガイドラインについて確認、同意しました

選択肢の項目を作成し、「複数回答」にチェックを入れて項目を用意します。

Power Automateの作成

受け取る値を確認する

まず、作成したFormsの回答を受け取れるようにします。

作りこむ前に、まずは回答された値がどのように入るか確認します。

すべてのオプションに上から順にチェックを入れてFormsから回答します。

実行結果で値を確認します。

実際の値を抜き出したものがこちらです。

["運用ルール・ガイドラインを確認し、同意しました","アカウント作成・利用ルールについて確認、同意しました","記事の作成、公開ルールについて確認、同意しました","その他、記事内容に関するガイドラインについて確認、同意しました"]

オプション選択肢がカンマで区切られてずらっと並んでいる事が分かりました。

分岐を設定する

今回は、すべての項目に同意しているか、そうでないなで分岐を分けたいと思います。

全項目に同意している場合、Formsのチェック項目を示す「以下の項目を確認し、同意出来たら…」の値が

先ほど確認した、次の値になる事が期待されます。

["運用ルール・ガイドラインを確認し、同意しました","アカウント作成・利用ルールについて確認、同意しました","記事の作成、公開ルールについて確認、同意しました","その他、記事内容に関するガイドラインについて確認、同意しました"]

よって、その項目と値を分岐の条件に使用してみます。(冒頭と末尾のかっこは除きます)

動作確認をする

これで、先ほどの「すべてのオプションに上から順にチェックを入れてFormsから回答」したデータを使ってフローを実行すると、一見うまくいきます。

現状の問題点

一見上手くいくので気づきにくいのですが、実はここまでの実装方法だと落とし穴があります。

Formsの複数選択オプションの値の生成は、「チェックを入れた順」になります。

なので、先ほどの様に「すべてのオプションに上から順にチェックを入れてFormsから回答」した場合と、「すべてのオプションに下から順にチェックを入れてFormsから回答」したものでは、値が異なります。

後者の時の値はこうなります。

["その他、記事内容に関するガイドラインについて確認、同意しました","記事の作成、公開ルールについて確認、同意しました","アカウント作成・利用ルールについて確認、同意しました","運用ルール・ガイドラインを確認し、同意しました"]

4番目の項目である「その他、記事内容に関するガイドラインについて確認、同意しました」が先に書かれている事が分かります。

そうすると、実際にはすべての項目にチェックが入っているにも関わらず、条件分岐では「同意していない」という扱いになってしまいます。

Power Automateの修正

実際には「上から順にチェック」と「下から順にチェック」以外にも、チェックを入れる順番は複数のパターンが考えられるので、すべてのパターンに対して分岐を用意するのは得策ではありません。

なので、「全項目に同意した時の文字列」ではなく、「全項目に同意した時の値の数」で判定するように修正したいと思います。

複数選択オプションの値を配列に変換する

Formsから入手した複数選択オプションの値は、そのままだと配列として扱ってくれないので、一度JSONの解析を挟みます。

スキーマについては、「サンプルから生成」をクリックし、

先ほどから使用している以下の値を

["運用ルール・ガイドラインを確認し、同意しました","アカウント作成・利用ルールについて確認、同意しました","記事の作成、公開ルールについて確認、同意しました","その他、記事内容に関するガイドラインについて確認、同意しました"]

サンプルとして貼り付けると、自動で生成してくれます。

実際のスキーマはこうなります。

{
    "type": "array",
    "items": {
        "type": "string"
    }
}

lengthで要素の数を計算する

続いて、先ほどのJSONで解析した値を元に、lenght関数を使用して、配列内に要素がいくつあるかを計算します。

learn.microsoft.com

式には次のようになります。

length(body('JSON_の解析'))

挙動の確認

lengthで処理した後の結果を確認するため、いったん適当な変数を用意して、値を見てみたいと思います。

要素の数(今回は同意項目の数)が4つであることが分かります。

チェックを入れる順番が違っていても、要素の数は変わりません。

条件分岐を修正する

条件分岐を見直します。先ほど計算した要素数を条件として利用し、4に等しい場合は「はい」の分岐へ、それ以外の場合は「いいえ」の分岐に行くようにします。

きちんと、「はい」の分岐になりました。

もちろん、チェック順が異なっていても同様です。

値が足りない場合は、「いいえ」の分岐になります。

これで、同意がすべてされていた時と、そうでない場合は処理を分けることが出来ました。

おわりに

実はこのネタが、実際に僕が社内で似たような仕組みを作ったときに、当初気づかずに文字列で処理してしまっていた際の失敗&解決案を元にしています。

同じような仕組みを考えている方の参考になれば幸いです。

執筆担当者プロフィール
舟越 匠

舟越 匠(日本ビジネスシステムズ株式会社)

人材開発部に所属。社内向けの技術研修をメインにしつつ、JBS Tech BlogやMS認定資格取得の推進役もやっています。資格としてはAzure Solutions Architect Expertを所持。好きなサービスはPower Automate / Logic Apps。好きなアーティストはZABADAK。

担当記事一覧