ご存知の方も少なくないようですが、タイトルにある通り SharePoint 2010 ベースのワークフローエンジンが利用できなくなります。といっても SharePoint Online の話で、オンプレミスとは状況が異なるので注意してください。

SharePoint 2010 ワークフローエンジンを使うワークフローは、早急に Power Automate もしくはその他のソリューションに切り替えていく準備をしておく必要があります。とはいえ、全く同等にフローが作れるわけではないのが、なかなか悩ましいところではあります。

Microsoft 社からの公式情報は次の通り。

「Support update for SharePoint 2010 workflows in Microsoft 365」

「SharePoint 2010 workflow retirement」

SharePoint 2010 ワークフロー エンジンとは何か?

SharePoint 2010 ワークフローエンジンと聞いて、ピンとこない方のために、少し歴史的背景をご紹介しましょう。

SharePoint はワークフロー機能を持っています。SharePoint Portal Server 2007からこの機能を利用して承認フローなどを構築できるようになっています。このワークフローを支えているのがワークフローエンジンであり、SharePoint Portal Server 2007 および SharePoint Server 2010ではワークフローエンジンを SharePoint 自体が内包してきました。

SharePoint Portal Server 2007では 2007用のエンジン、SharePoint Server 2010 は 2010 用のエンジンをそれぞれに持っています。それぞれをベースとしたワークフローテンプレートも用意されており、サイトコレクションの機能(フィーチャー)にそれぞれのテンプレートの有効化を行う機能があります。

たとえば、SharePoint 2007 用は次の機能をアクティブ化すると利用できるようになっています(といっても、古いのでもう Online では使っているところはないと思います。今のところ SharePoint Online でも設定は名残として残っていたので参考までに掲載しています)。

SharePoint 2010 のエンジンを使ったビルトインのテンプレートを利用するときは次の「ワークフロー」機能をアクティブ化します。

この機能をアクティブ化するとリストやライブラリにビルトインのワークフローテンプレートを追加して利用できるようになっています。

ビルトインのテンプレートは次の通りであり、フィードバックの収集、署名の収集などがあります。

ただし、このエンジンはSharePoint 内で動作していたこともあり、スケーラビリティに欠けるなど課題も見えてきました。そこで SharePoint Server 2013 からは従来の SharePoint 2010 エンジンも利用できるようにしつつ、新たなエンジンとして SharePoint 2013 エンジンを提供し始めます。これは SharePoint 内に含まれてはおらず、別途 ワークフローエンジン用にサーバーを構築してエンジンをインストールする必要がありました。要するに、エンジンが外付けされることになったわけです。これによってスケーラビリティの問題なども解消できるし、従来組めなかったフローロジックも組めるようになるなど恩恵はあったものの、SharePoint のアクセス権限設定が柔軟に設定できないなどの問題も抱えていました。そこで、SharePoint 2013 エンジンと SharePoint 2010 エンジンを組み合わせて、互いのいいとこどりをするようなフロー構築もできるようになっています。

このような背景の中、SharePoint Server 2010 以降では SharePoint Designer 使った独自のワークフロー開発なども盛んにおこなわれました。ちなみに、SharePoint Designer 2013 で独自にワークフローを作るときには、どちらのエンジンをベースにフローを作るのかを選んでから作成するようになっています。

SharePoint 2010 および 2013 ワークフローエンジンは今後どうなるのか?

ここまでの経緯で SharePoint 2010 ワークフローエンジンとは何かがある程度、把握できたと思います。

今回 Microsoft からのアナウンスによると、SharePoint 2010 ワークフローエンジンを使ったフローは次のような段階を経て、利用できなくなります。

• 2020年8月1日から、SharePoint 2010 ワークフロー群は、新たな作成されたテナントに関しては利用できなくなる
• 2020年11月1日から、既存のテナントから SharePoint 2010 ワークフローの実行および作成機能の削除を開始する

SharePoint 2013 エンジンに関しては利用は非推奨とはなるものの、引き続きサポートされるとのこと。2020年11月以降、新規テナントでは SharePoint 2013 ワークフローエンジンの利用も既定ではオフにされます。ただし、必要があれば PowerShellスクリプトを使って SharePoint 2013 ベースのワークフローをアクティブ化できるそうです。

またオンプレミスの SharePoint 2016 と 2019 サーバーに関してはどちらのエンジンも 2026年までは引き続きサポートされます。

最後に、これからに備えて

以上のように今から10年前に登場したエンジンも終焉を迎えることとなりそうです。既に組織内でこうしたフローを使っている場合は早急に確認をし、対応を考える必要があります。SharePoint の開発コミュニティがモダン化対応をチェックするためのツールとして「 SharePoint Modernization Scanner 」をオープンソースとしてGitHub に公開しているので、まずはこれを使ってフローの洗い出しをしましょうということのようです。ただし、今日もちょうどSharePoint モダンポータルの研修を実施しており、このツールの話をするのですが、このツールは実は SharePoint Online の管理者、つまり組織全体の管理者でないと設定できない部分があります。この部分が少しネックになるかもしれません。大企業だと複数のグループ企業を抱えていますが、要するに親会社側でないとこれらの設定ができないので手軽に試せるとは限らないのです。これに関しては、各組織でうまく連携を取る必要があるでしょう。

それから、今あるフローをそのままPower Automate やその他のサービスに移行しようと考えるようとしているのであれば、ちょっと待ってください!

日本の組織では大抵の場合、その対象が「承認」フローだと思います。是非、次のことを考えてみてください。 

新型コロナにより仕事の仕方も大きく変わってきていて、さらにこうした大きな変化の節目でもあります。この際に可能な限り業務を見直して、本当にそのフローが必要なのか組織内で議論をしてみてはいかがでしょうか。絶好のタイミングとみることもできるかもしれません。

「その承認は本当に必要なのか?」

いろんな方に話を伺うと、フローを作る側の人は、少なからずそう感じているフローがあるようです。

もしかしたら、紙の判子で書類を回していたころから、引き続き今までやってきたからという理由で続けているところはありませんか? 団塊の世代が活躍していたころからあるプロセスだったりしませんか? だとしたら一度見直す時期では? そもそも、その承認プロセスは形骸化していなませんか?

この人手不足の中、少ない人材でいろんな仕事を効率よく捌く必要があります。見直すタイミングも必要ではないでしょうか? 年功序列で、先輩後輩の関係があり、先輩は無茶もいうけど、後輩の面倒もよく見てくれていたという義理人情もまだまだあったころは、承認プロセスには責任の所在を明らかにするとともに、本当に責任もとっていた方々も少なくなかったのではないかと想像しています。ですが、責任の所在といっても形式だけになっていませんか?  承認以外にもやりようがあるかもしれません。本当は迅速な情報の可視化が必要なのに、人海戦術でチェックするために承認フローをつかっていたりしませんか? そうなると場合によっては、承認ではなくて業務プロセスをスムーズに進めることに時間とお金と労力をかけていきたい。

もちろん、承認が不可欠な業務があるのは事実ですが、見直しは必要だと感じています。

業務プロセスを見直しながら、プロセスをより効率よく進めていけるように Power Automate を使って自動化できる部分は自動化することを考えてみてはいかがでしょうか? Power Automate = ワークフロー = 承認と考えている方が、(特に SharePoint ユーザーでは) 結構な確率でいらっしゃると思いますが、そうではありません。Power Automate が真価を発揮するのは、これまでになかった AI との連携やチャットボット連携なども含む、新しい切り口で業務を支援できるポテンシャルを持っています。

そして、Power Automate を独学で学ぶ十分な時間がなかなか取れない方は、是非弊社の研修もご利用ください(最後は宣伝もかねて)。

2020年7月16～17日に初回実施となりますが、「業務効率を向上させる Power Automate 実践演習 (OH-O365-205)」は Power Automate をちょっと触ってみたけど、もう一歩、詳細なフローが組めるようになりたい方向けの中級レベルの方向けの研修内容になっています。Power Automate を使ったフローの移行を考えいる方に最適です。

今回は 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 内で Flow ボットを使って機密保持契約書を送付する

Flow ボットは手動で開始できるようになっていますが、Run flow コマンドで開始するには次のお約束があります。

• 既定の環境にフローを作る
• 入力がないフロー、またはスケジュールに基づいて実行されるフローであること

このあたりのことは Flow ボットに "Learn more" コマンドを送信すれば教えてくれます。

それでは! ということで早速上記のルールにのっとって作成するわけですが、手っ取り早いのはモバイルのFlow ボタンにある「手動でフローをトリガーする」トリガーを使ったフローです。

これを利用するのですが、Flow ボタンのトリガーを使って作成しても、List flows にフローが出てこないケースがあるのです。

順を追って説明します。

Flow のトリガーを追加し、コードのプレビューをしてみましょう。

これを見ると次のように入力が空なのが分かります。

このままフローを構築すればいいわけですが、途中のアクションでフローの作成者情報を取得しましょう。例えば次のようにトリガーしたユーザー名を変数に格納してみます。

この状態で再び「手動でフローをトリガーします」のコードビューを確認してみましょう。次のように変化しているはずです。

つまり、トリガーしたユーザーの情報を取得するために入力パラメータが生成されてしまっているのです。

このようになると Flow bot からは呼び出せなくなります。

検証していて、非常に嵌ったところです。

皆さんも試すときには、何もパラメータのないトリガーに気を付けてフローを構築してみるようにしてください!

Microsoft Teams には Flow アプリを追加できるようになっています(テナントによっては不可になっていることもあります)。

このアプリ内ではフローの作成や管理はもちろん、自分と対話できるフローボットが利用できます。このフローボット自体 Power Automate を使って作成できます。

利用イメージがしやすいように、これを使って SharePoint に格納されている機密保持契約書を手軽に先方に送付するというシナリオをご紹介しましょう。このフローではTeamsのコネクターを使っていますが、いずれも現時点ではプレビューであり、フロー構築時にはいくつかの課題もあります。

構築方法については今回は深入りしませんが、まずはどんなことができるのかを知ってもらえれば、何か業務改善のヒントになることもあるのではないかと思っています。

詳しくはビデオを使って説明していますのでご覧ください。

基本的な flow bot の作り方はまた別の記事で紹介します。

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 内のファイルタブには関連づいているフォルダー名が表示されるようになっているので、これを手掛かりにするとよいでしょう。

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