0. INDEX

はじめに
「承認の作成」を弄ってみる
様々な罠
あとがき

1. はじめに

どうも、弊社のバカ野郎担当です。
Qiitaサボりすぎてボスから「Qiitaを記事書けー記事書けー」という幻覚無言の圧を
感じたようなそうでないような気がしてきたので重い腰を上げることにします。

とりあえず、Automateの基本的なことに触れつつ、Teamsの承認アプリにピロンと承認依頼を出して、その回答を確認するところまでやってみます。

↓こういうやつ

具体的な流れだとフローで言うならこんな感じに作って、Automateのテストで出力を確認します。
手動トリガー ⇒ 承認の作成/待機

よかったらセルフハンズオン的な感じで一緒に触ってみてください。
開発環境とかは整ってる前提ですすめます。

2. 「承認の作成」を弄ってみる

2.1. フローを新規に作成する

作成 ⇒ （任意のフロー） と進めてください。

スキップ をしないなら青枠のように「 フロー名 を入力 ⇒ フローを手動でトリガーする を選択 ⇒ 作成 ボタン押下」して下さい。

Automate的には、アタマの箱を トリガー と呼ぶそうだが、起動条件を持っていて必ずフローの先頭に置くという事を知ってればいいだろう。
それ以外の箱は アクション という。

この辺を見るといろいろ書いてあるけど、 アタマから始まってケツで終わるという本質 は一緒。

トリガーの種類

自動
- クラウドフローの基本動作。
  SharePointのファイルが更新されただの、メールが来ただの365上のいろんな条件が指定できる。
  これを知ってるだけでAutomateで何ができるのかってのを提案する手助けになるだろう。
即時/手動
- 主にApps用。
  AppsのGUIからボタンをクリックしたとか、フローを直接起動しただの能動的な条件を指定できる。
  キャンバスアプリを作ったり、検証用の手動起動なんかに使うことが多いだろう。
スケジューリング
- いわゆるバッチ。
  任意の時や一定間隔で起動するなどの条件を指定できる。

2.2. フローを保存する

保存をするには、「トリガー」「1つ以上のアクション」を置く必要がある。
スクショを参考にして保存しよう。

「フローを手動でトリガーする」を置こう

同様に「+」からアクション名の一部で検索し、「変数を初期化する」を置こう。保存したいが為の NOP¹ なのでエラーが出なければ何でもいい。最後に消します。

変数を設定後、フローの名前を変更して保存しよう。
1トリガー、1アクション、フロー名を設定する事で保存できるようになる。

2.3. 承認をしよう！

「承認の作成」をスクショを参考に並べてください。

設定はこんな感じで。 承認の種類 は カスタム応答-すべてのユーザの承認が必須とします。後で結果を取得してみたいしね！ 応答オプションは、Teams承認アプリで選択できる「ドロップダウンリスト」の内容になります。担当者` には、Teams承認アプリで通知を送りたい先。つまり、承認の依頼先を設定します。

次に「承認の待機」を置いて、「承認の作成」の 承認ID を設定します。
「承認の待機」アクションは、Teams承認アプリで通知を受けたユーザが応答を返すまで、 同期処理 として止まっていてくれます。
逆に言えば、「承認の作成」と「承認の待機」は同じフロー内に入れておく必要がありそうだ。この辺はまだ検証が足りないので、間違ってるかもしれない。

2.4. 実行してみよう

保存 をして テスト を押下してください。

手動 でOK。過去の実行引数とかを利用したい場合は、 自動 から選択可能、デバッグに役立つ。

初めて外部サービス（ここでは承認アプリ）を使う場合、フローから実行してもよいかどうかの許可をする画面が出るので、問題がなければ 続行 ボタンを押下してください。

テスト画面に移行。実行状況がわかります。

Teamsの承認を確認すると、承認依頼が来ています。
コメント を入力し、 選択肢 を選び、送信 ボタンを押下してください。

2.5. 結果を確認してみよう

テスト画面では、結果が確認できるようになっています。

JSONに含まれている項目は、当然フロー内で取得できます。

ただ、 回答数コメント のように 回答数 が頭についている項目は、イテレーターになっているようで「For each（それぞれに適用）」で分解して取得をするか、 first() と outputs() の組み合わせで取得する必要がありそうです。

3. 様々な罠

3.1. フロー内にエラーがあると保存できない

なので、 1アクションを置いたら設定して保存する。 をなるべく実践した方が良いでしょう。もし、ミスに気付かず作業を続けてしまうと、それだけミスってる場所の特定は困難になります。
一応、ミスっているらしいアクションを教えてはくれるが、「条件」、「それぞれに適用する」等を使い始めると、ミスったアクションを含む「条件」ごとエラー表示になり、非常に対処しにくくなります。

以下のスクショは保存失敗時のメッセージが意味不明なパターン。ちなみに、名前が空白なものはありません。
解決できない場合は、いろいろ削って保存しなおすしかない為、ゾーン²に突入して一気に書いてしまうと死ねます。

3.2. 「承認の作成」と「承認の待機」は1つのフローに書く必要がある

イベント駆動に慣れていると、「承認者が回答をしたとき」のようなトリガーを探してしまいそうになりますが、これは見つけられませんでした。
とりあえず、現状では同一フロー内に書く必要があると思っていたほうが良さそうです。³

3.3. 「承認の作成」の「承認の種類」の一覧と使い分け

こんな感じです。

署名の種類	「承認の作成」の選択肢	「承認の待機」の待機解除条件	多段階承認
カスタム応答 - 1つの応答を待機	任意のテキストで指定	承認者の一人が回答する	非対応
カスタム応答 - すべての応答を待機	任意のテキストで指定	承認者の全員が回答する	非対応
承認/拒否 - すべてのユーザーの承認が必要	「承認」or「却下」で固定	承認者の全員が回答する	非対応
承認/拒否 - 最初に応答	「承認」or「却下」で固定	承認者の一人が回答する	非対応
連続した承認 - すべての応答を待機	「承認」or「却下」で固定	承認者の全員が回答する	対応

多段階を踏める 連続した承認 を思わず使いたくなる事でしょう！
承認処理の選択肢を自由に決められる カスタム応答 - xxx も使いたいでしょう！
でも、 同時に2つは使えない のです…orz
Teams承認アプリ上で、承認ワークフローが視覚的に繋がらない問題には目をつぶって、別途視覚化したApps等を用意するなどの工夫が必要です。
幸い、Teams承認アプリには、マークダウンで詳細が書けるので別アプリへの誘導自体は可能かと思います。

3.4. 「条件」と「それぞれに適用」、「Do until」のご利用は計画的に

Automateには、ループ抜けのためのbreakや、フローの途中終了的なreturnがありません。
なので、可能であれば1フローの処理はごくごく単純なものにしたほうが良いでしょう。
以下のスクショは適当に条件を入れ子にしてみましたがイメージは伝わるでしょうか。業務利用で条件分岐を考えるとこのくらいは速攻で分岐すると思います。

例えば、条件False側はもうやることがない…となっても、条件スコープが終われば、True/Falseの情報のルートを考慮しなければならないのは割とややこしい実装になると思います。

3.5. アクション名の扱いが難しい

これ、私の一番の不満なのですが、アクション名といえばUI上箱に見えている文字です。
アクションのデフォルト名以外には変更は自由⁴なので、こういう騙しが可能です。

こんな感じで。せめてアイコンがアクション毎に異なっていればまた違った感想だったと思います。

4. あとがき

今回は、最近Automateに触り始めて、うぎゃあああああとなった点などを含めつつ、「承認の作成」の癖について書いてみました。
SharePointなどの365上のデータに触る部分はAPIを叩くよりも簡単だと感じたので、Automate自体をREST APIサーバに仕立てて、Azure Functionsなど別システムから叩きに行くといったのは良いかもと思いました。
それはそれとして…うん、ウチAutomate嫌いだわ…。orz

NOPまたはNOOPと書き、No Operation（何もしない）の意味。通称ノップ。カルネのようにAutomateにもNOPが欲しい…。あ、いや、return と break の方が欲しいかも…。 ↩
ここではプログラマが周りを気にせず、時間を忘れて作業をする超集中モード（通称:話しかけんなモード）を指す。難解な設計や実装でも素早く仕上げる事はできるものの、その作業過程はウルトラCの連続であり、他人はおろか我に返ったプログラマ自身も再現が難しくなったりする。Automateとゾーンの相性は極めて悪いと思う。 ↩
Dataverse（要プレミアムライセンス）を使えばあるのかな…？ ↩
例えば「承認の作成」アクションに「承認の作成その2」とフロー内でつけていた場合、「承認の作成」というアクション名は存在していないが、別のアクションに「承認の作成」という名前は付けられないようです。 ↩