今回は SharePoint 開発経験者向けのお話。

Power Automate では SharePoint の REST APIが呼び出せます。

本題に入る前に少し状況の補足をしておきましょう。

クラシックサイトでは気軽に JavaScript を埋め込めていましたが、これにより管理者が把握できないスクリプトも溢れることになりました。さらには、何かするにも JavaScript を書く必要があるというのはエンドユーザーにとってはハードルが高い。サイロ化したスクリプトを管理下におけるよう、モダンサイトでは SharePoint Framework を使ってサイト管理者の管理下にあるスクリプトのみが実行できるように振る舞いが変わっています。またエンドユーザーでも手軽にアプリが作れるように Power Platform と SharePoint は連携できるようになっているわけです。

こうした背景から、今まで JSOM (JavaScript Object Model)ゃREST APIを JavaScript からアプローチを一部は Power Automate や Power Apps などに置き換えていく方向も考えていく必要があります。

そこで冒頭の話に戻ります。Power Automate では SharePoint REST API を呼び出せるので、これまで JSOM や REST API で培ってきた開発ノウハウを生かせる部分も多く存在します。

今回、ブログの題材は SharePoint Designer 2013 の持っていた機能の一部置き換えをしようという試みです。その一つがリストの表示・非表示。

さて、Power Automate などで処理している際にも、ユーザーには直接目につかないように隠しリストを作りたいというケースも少なくない。こうした処理を Power Apps と Power Automate で処理してやろうという話です。次のビデオでは実際の動作が確認できます。まだアプリは改善の余地はありますが、それは追々機能を拡充していく予定です。

このフローでのポイントは SharePoint コネクターの「SharePoint に HTTP要求を送信します」アクションを使うことです。今回は更新処理であるため POST します。また、リストのアップデートを行う必要があるわけですが、従来のようなページ上で JavaScript を実行するときとは異なり、X-REQUESTDIGEST の値を指定する必要はありません。

さて利用したフローの全体画面を掲載しておきます。REST API に慣れている方は、このあたりは問題なく利用できるでしょう。

Microsoft Teams 内の各チームには[ファイル]タブが用意されています。このファイルタブの実体は SharePoint サイトです。

もっというと、チーム内の[ファイル]タブは SharePoint サイト上にある「ドキュメント」ライブラリ内のチャネルごとに生成されるフォルダーが紐づいています。しかし、Teams の[ファイル]タブは、SharePoint の標準的な機能の一部が実装されていません。もちろん、あくまで[ファイル]タブ経由で利用するとという限定的な話であり、[ファイル]タブのコマンドバーから "SharePoint で開く" をクリックすることで、Webブラウザーから直接 SharePoint のライブラリにアクセスすれば、標準機能がフルに利用できます。

※補足 : Teams がリリースされて間もないころはSharePoint が持つファイル管理機能のごく基本的な機能のみしか提供されていなかったのですが、数か月前からだいぶ SharePoint のオリジナルの持つ機能に近づいては来ています。

そのため、今回のブログのタイトルにあるような Power Automate を使った承認フローを実装するには、少し工夫が必要です。

Webブラウザーから直接SharePointサイトを利用するときには、格納しているファイルに対して承認フローを開始する方法としてはファイルのプロパティを確認し、例えば "下書き" から "公開" といった値に変更したときに承認フローを自動的に開始できるようにすることも少なくありません。しかし、[ファイル]タブでは現時点(2020/4/18)ではプロパティを編集できません。さらに、手動でワークフローを開始するにもフローを手動開始するコマンドメニューがありません。SharePoint 標準では本来はできることです。

そこで、[ファイル]タブを使ってフローを開始するのであれば、手動開始とプロパティの値をトリガーにすることはあきらめる必要があります。「ファイルを新規に作成したら」という自動的にフローが開始されるトリガーを使うのが妥当でしょう。

例えば、[ファイル] タブ内の特定のフォルダーにファイルを移動したらフローが開始されるというような実装を考えます。ただここで問題なのが、SharePoint コネクターのトリガーによってはサブフォルダーからはフローが開始されないものがあるということ。[ファイル]タブはサブフォルダーに紐づいているので、ここが重要なのです。

以上のことから、トリガーには次のいずれかを使うようにします。このトリガーはサブフォルダーでも動作します。

• ファイルが作成されたとき(プロパティのみ)
• ファイルが作成または変更されたとき(プロパティのみ)

自動開始を前提とするので、フローを起動したときに承認者を選択させることができないので、最初から承認者を固定で指定しておくか、上司の自動取得をするなど何かしら工夫をしておく必要があります。

ところで、トリガーを設定するときですが、SharePoint サイトとの関係が把握できていないとどのフォルダーをトリガ―指定すればよいのか迷うところです。チャネルとフォルダーの関係を図解しておくと次のようになります。トリガーを構成するときには、この図を念頭に置いたうえで、チーム名と同じ名前の SharePoint サイトのURLとフォルダーを指定するようにしましょう。

なお、チャネルを最初に作ったときに(もっと正確にいうと、チャネルを作成後に[ファイル]タブに初回アクセスしたときに生成) SharePoint側にフォルダーが作成されるのですが、フォルダー生成後はチャネル名を変更しても既存のフォルダ名は変更されません。そのため、現在 Teams 内のファイルタブには関連づいているフォルダー名が表示されるようになっているので、これを手掛かりにするとよいでしょう。

以上を踏まえ、最もシンプルな承認フローを構築すると次のようになります。ここでは細かい設定については触れませんが、詳細は例えば、既存の承認用のテンプレートを使いトリガー部分を差し替えるなどしてみてください。

自分の備忘録として。

=======

以前作成していた Power Apps アプリを久しぶりに開いたら次のメッセージが表示されました。

現在プレビューの以下の機能が近く正式リリースになるようですね。

• 遅延読み込み
• 信頼性の高い Concurrent 関数

そのためアプリの設定でも既定でオンになっていました。

遅延読み込みについては下記のパフォーマンスに関する記事が参考になります。

Optimize canvas-app performance in Power Apps

また Concurrent 関数は 2018年7月に追加された機能ですが、この機能が強化されるということを意味します。

Concurrent 関数 - PowerApps

複数の数式をそれぞれ同時に評価します。 Evaluates multiple formulas concurrently with one another. The 通常、複数の数式は、それぞれが順番に評価される、 Normally, multiple formulas are evaluated by chaining them together with the Concurrent 関数では、同時に複数の数式を評価します。 Concurrent function evaluates multiple formulas at the same time. ; 演算子と共に連結することによって評価されます。 ; operator, which evaluates each sequentially in order. アプリによって操作を同時に実行すると、同じ結果がユーザーに返されるまでの時間は短くなります。 When the app performs operations concurrently, users wait less for the same result.

PowerApps でデータソースを SharePoint リストにしているとき、日付と時刻の列が空にできないことがあります。そんなときの工夫の方法は、アプリの詳細設定で実験的な機能の一つである「数式レベルのエラー処理」機能をオンにすることです。

実験的な機能はあくまでも実験段階のものであるため、今後大幅な機能変更や機能が完全に消滅する可能性もあります。そのため残念ながら現在のところは運用環境での利用は難しいのですが、この機能をオンにすることで Blank関数を使って Null値を渡せるのです。

実際に SharePoint リストから生成した PowerAppsアプリの動作を見てみましょう。次のビデオで示している通り、日付と時刻列の値を空にできません。

キチンと空の値で更新するには、先ほどの「数式レベルのエラー処理」機能をオンにして、アプリを保存後、いったんアプリ編集を終了します。こうしないと機能が有効になりません。再びアプリを編集します。例えば、この例では日付と時刻列部分のカードコントロールの Updateプロパティの値を「DataCardValue6.SelectedDate」から「If(!IsBlank(DataCardValue6.SelectedDate), DataCardValue6.SelectedDate, Blank()) 」に変更します。これにより、次のビデオのように日付と時刻のフィールドが空として更新されたことが確認できるはずです。お試しあれ。

SharePoint Online のモダンなカスタム リストでは標準のリストフォームを PowerApps を使ってカスタマイズできます。ちなみに、リストフォームのカスタマイズではなく、PowerApps のアプリからデータソースとして SharePoint リストを利用する場合とは話が異なるので注意してください。あくまでも、リストフォームのカスタマイズです。

カスタム リストフォームの削除に関して、気になる挙動があるため情報共有しておきます。なお、管理者の方でないとあまりピンと来ないかもしれません。

SharePoint リストフォームの削除手順

リストフォームは次の手順で削除します。

当該リストやサイトを削除したらどうなる?

ところで、上記の手順を実施せずにリストやサイトを削除したらどうなるでしょうか? これが問題なのです。上記の手順を踏まえず、リストやサイトを削除すると当然 PowerApps アプリ自体は使えなくなるのですが、PowerAppsの管理センターから確認すると、一覧に残っているのです。一見、わからないのですが、よくよく作成先のURLを確認すると既に削除済みのリストやサイトに紐づいていたアプリであることがわかるという状態です。

下記の図がPowerApps管理センターで、赤枠の部分に "SharePoint Form" とあるのがリストフォームをカスタマイズした際に生成されたアプリです。

リストやサイトを削除すれば、自動的に PowerApps アプリも削除されると思っていたのですが、ちょっとした落とし穴です。しかも、PoweAppsの管理センターからはリソースの確認はできますが削除はできません。管理者がアプリを削除するには PowerShellを使う必要がありますし、PowerShellを使った削除などの管理には PowerApps の Plan 2 が必要です。

ユーザーに対して特に影響はありませんが、管理者サイドからするとアプリ一覧に今後使うことのない "ゴミ" とも言える PowerAppsアプリ(厳密には SharePoint Form)がずっと残り続けるため、一覧を確認する際にはこれらの情報を省いておく必要がありそうです。なお PowerShellを使っても当該リストが削除されているかどうかはわかりません。SharePoint管理センターからもどのリストが PowerApps でカスタマイズされているかはわかりません。これも厄介な点です。

1票にご協力を

日本マイクロソフト株式会社のサポートにサポート依頼をして、本件は連絡済みですが、現時点ではリストやサイト削除時に一緒にアプリも完全削除してくれる動作ではないとのこと。サポートの方からも下記のURLに本社の開発チーム向けに改善リクエストを上げていただきました。本機能の実装に賛同いただける方は1票を投じていただければと思います。※どなたでも投票可能です。

Delete SharePoint customized form from PowerApps admin center.

We can use PowerApps to customize the SharePoint list form, but we can not delete customized forms in the PowerApps Admin Center. We need to delete them from SharePoint. Customized form will remain on PowerApps If we deleted the SharePoint list. It is causing trouble in management because there is n...