前回まで7回にわたってMS-Flowを使ったDynamics365 financialsの承認ワークフローの実例を照会しました。今回は実際に作ってみて気づいた点・気になった点をいくつかピックアップして紹介します。
1. Dynamics365側の承認ユーザーID
以前の記事でワークローの管理者と承認依頼者と承認者を分けてワークフローを回してみましたが、その際Dynamics365のワークフローには承認者のユーザーIDは記録されません。
Dynamics365のFlowEntriesという明細に承認依頼明細の作成者と最終更新者が記録される仕掛けになっています。NAVベースのワークフローだと作成者＝申請者、最終更新者が承認者になるわけですが、MS-Flowでワークフローを処理すると最終更新者がMS-FlowのWF管理者になります。より正確に言うと、MS-FlowのワークフローでDynamics365 for Financialsへの接続に使用したユーザーでDynamics365の更新処理が実行されるのでMS-Flowの承認者では記録されません。内部統制的な目線で見て、承認者の記録が残らないのはどうか？とも思いましたが、MS-Flow側には残っているのでよいということなのでしょう。逆に、承認管理はMS-Flow側に切り出すことでDynamics365側のライセンス料を節約できるのがメリットになるかと思います。
2. メールに記載する伝票情報の取得
承認依頼メールには伝票番号や得意先などの情報が記載されています。これはSales Order Workflow Templateだと2番目に登場する「GetItem」アクションで取得した情報であり、GetItemアクションの後続のアクションでGetItemにて取得した情報をメール送信アクションの中の記述にて変数として使用しています。ある伝票のWF処理にて具体的にどんな値が設定されているかはWFの実行履歴から見る事が出来ます。
3. 並列承認におけるAND承認、OR承認
ワークフローにおいてはある承認ステップにおいて「順序を問わず複数人が承認することとしたい」という場合があります。問題はこの複数人がAnd承認（全員の承認が必要）なのかOr承認（任意の一人の承認が必要）なのか、です。NAVベースのワークフローでは非常に残念ながらAnd承認しか対応していないのですが、MS-Flowについてはどちらも対応できるようです。これはMS-Flow側の大きなアドバンテージだと思います。（実際の動作検証は、、またの機会にします。）
4. メールを使わない承認
前回までの実例紹介では承認者は受け取ったメール上で承認処理を行っていましたが、MS-Flowの画面でもできます。というか、もともとはこちらが本筋で、メールはむしろアドインなのだと思います。
5. ワークフローテンプレートの「使用回数」の謎
ワークフローテンプレートには作成者情報に加えて「使用回数」があります。前回の記事にて各種ワークフローテンプレートを一通り動かしてみました。始める前に見たところ使用回数が入っていないテンプレートも多く、「もしかして自分が世界初の使用者か？！」とwktkしたのですが、実際に使ってみても回数は増えませんでした。。残念。
MS-Flowは面白くて掘り下げ甲斐がありますが、、いったんこのくらいにしておきます。（NAVのテンプレートとか正直気になっているのですがｗ）
次回以降はCRMとの接続に挑戦してみようと思います。