SharePointワークフロー廃止後はどうする？移行先の選び方・費用・注意点を解説
SharePointのワークフローが廃止され、申請や承認をどう続ければよいか迷っている担当者も多いのではないでしょうか。
SharePoint Onlineの2013ワークフローは、2026年4月2日に廃止済みです。
SharePoint自体は終了していないので、業務に合った別の仕組みへ切り替えて申請や承認を続けられます。
本記事では、廃止対象と確認方法、移行先の選び方、費用や注意点を解説します。
申請先を案内する社内ポータルの見直しも紹介しているので、自社の対応を考える際にお役立てください。
※本記事の廃止日・製品情報は、2026年10月12日時点で確認したMicrosoft公式情報に基づいています。
SharePointワークフローはいつ廃止？対象機能と終了スケジュール
廃止の影響を判断するには、利用している環境とワークフローの種類を分けて確認する必要があります。
「2010」「2013」はワークフロー基盤の種類を表しており、現在契約しているSharePointのプラン名を指すものではありません。
まずは申請・承認に使っていた仕組みを確認し、終了日と対象範囲を押さえましょう。
SharePointワークフローとは？申請・承認を自動化する仕組み
ワークフローは、申請から承認、結果の通知までを決められた順序で進める仕組みです。
例えば、社員がリストに購入申請を登録すると、上司へ承認依頼を送り、承認後に経理へ通知する流れを自動化できます。
承認依頼を自動で送れるので、メールを転送する手間や連絡漏れを減らせます。
SharePoint Onlineで廃止されたのは、従来のSharePoint 2010・2013ワークフロー基盤です。
SharePointに関わる自動処理がすべて廃止されたわけではありません。
Power Automateで作成したフローとは区別して、自社の申請がどの仕組みで動くか確認しましょう。
SharePoint 2010・2013ワークフローの終了スケジュール
SharePoint Onlineの2010ワークフローは、2020年11月1日に廃止されました。
2013ワークフローは、新規テナントで2024年4月2日に無効化され、既存テナントでも2026年4月2日に廃止済みです。
テナントとは、企業ごとに用意されたMicrosoft 365の利用環境を指します。
2026年10月現在、旧ワークフローを使っていた業務を続けるには、別の仕組みへの切り替えが必要です。
申請画面が残っていても自動処理が動くとは限りません。
未処理の案件がないか、業務担当者と管理者で確認しましょう。
SharePoint Onlineとオンプレミスの対象範囲の違い
クラウドのSharePoint Onlineと、自社サーバーなどで運用するSharePoint Serverでは、終了条件が異なります。
Onlineの2026年4月2日という期限を、オンプレミスへ一律に当てはめないようにしましょう。
Server 2016・2019は、2026年7月に製品のサポートが終了しました。
Subscription Editionの2010ワークフローも、2026年7月14日にサポートが終了しています。
一方でSubscription Editionの2013ワークフローは、それ以降もサポート対象です。
Microsoftは、2013ワークフローを動かす仕組みをSharePoint Workflow Managerへ更新するよう推奨しています。
編集ツールのSharePoint Designer 2013は2026年7月14日にサポートが終了したので、基盤とツールを分けて確認しましょう。
SharePoint自体の終了・アドイン廃止との違い
終了したのは旧ワークフロー基盤であり、SharePoint Onlineのサイトや文書管理サービス全体ではありません。
社内ポータル全体を他のサービスへ移す前に、廃止の影響を受ける機能を確認しましょう。
また、SharePointアドインもOnlineで2026年4月2日に廃止されましたが、ワークフローとは別の仕組みです。
独自の申請画面や外部連携がアドインを使っている場合は、画面と自動処理の両方を調べる必要があります。
画面が開けるだけで正常と判断せず、申請から通知までの動作を確認してください。
廃止で承認・申請業務はどうなる？自社への影響と確認方法
申請フォームを開くことができても、承認依頼や結果の反映が止まっている場合があります。
設定を調べるだけでなく、実際の申請が承認や通知まで進んでいるか確認してください。
申請データと履歴を調べ、影響のある業務を洗い出した上で、暫定対応と移行の優先順位を決めましょう。
稟議・申請・文書承認への影響
旧ワークフローを使う稟議や休暇申請、文書承認では、承認依頼の送信や担当者への振り分けが止まるおそれがあります。
申請内容がリストに保存されても、次の処理へ進んでいないケースには注意が必要です。
例えば、購入申請が登録されても経理に通知が届かなければ、発注や支払いが遅れるおそれがあります。
申請件数と完了件数を照合し、担当部署に未処理の案件を確認してもらいましょう。
ポータルのお知らせに加え、影響を受ける利用者へ対応方法を伝えると、同じ申請の重複登録も防ぎやすくなります。
処理中の申請や承認履歴の確認
旧ワークフローで処理中だった申請が、新しいフローへ自動で引き継がれるとは限りません。
申請番号、申請者、最終承認者、処理状況を整理し、再申請する案件と手作業で完了させる案件を分けましょう。
履歴を保存したリストや通知メールなど、今も確認できる記録を調べてください。
廃止後にすべての履歴を取り出せるとは限らないので、記録が不足している申請は業務担当者に経緯を確認します。
保存できる記録は社内の保管ルールに沿って残し、旧申請と新申請の対応表を作ると、後から経緯を追いやすくなります。
自社で利用しているワークフローの調べ方
サイト管理者に、対象のリストや文書ライブラリの設定、過去の設計書、申請通知メールを確認してもらいましょう。
Power Automateで作成したフローと、旧SharePointワークフローを分けて一覧にすると、廃止対象を確認しやすくなります。
Microsoftの廃止案内では、調査手段としてMicrosoft 365 Assessment toolが紹介されています。
ただし、廃止後に旧フローの情報をすべて取得できるとは限りません。
最新の移行ガイドに沿って、保存済みの調査結果や設計書を確認しましょう。
各部署の申請フォームや連携している外部製品についても、旧ワークフローを利用していないか確認してください。
現在使われていないサイトに残っているワークフローの設定も、調査対象に含めましょう。
停止した業務の暫定対応と優先順位
支払いや契約、社員の入退社など、遅れると影響が広がる業務から対応しましょう。
切り替えに時間がかかる場合は、申請台帳とメールなどで一時的に承認を進める方法もあります。
その際は、申請番号、承認者、日時、判断理由を残し、誰が台帳を更新するか決めることが大切です。
台帳を閲覧・編集できる人を決め、個人のメールだけに記録が残らないようにしてください。
ポータルには暫定の申請先と問い合わせ窓口を掲載しましょう。
新しいフローへ切り替える前に、未完了の申請を照合して二重処理を防ぎます。
SharePointワークフロー廃止後の代替手段と選び方【比較表付き】
SharePointワークフロー廃止後の移行先は、承認ルートの複雑さや利用中のシステムに合わせて、次の3つから検討しましょう。
- Microsoft 365と連携して申請・通知を自動化するならPower Automate
- 簡単な承認業務ならSharePointの標準機能
- 複雑な申請・承認業務なら専用ワークフロー製品
ここでは、上記3つの代替手段と選び方を、比較表とともに解説します。
機能だけでなく、費用や導入後の管理負担も比べ、自社に合う移行先を選びましょう。
| 比較項目 | Power Automate | SharePointの標準機能 | 専用ワークフロー製品 |
| 向いている業務 | Microsoft 365と連携する申請・通知 | 項目や文書の簡単な承認 | 複雑な稟議や全社共通の申請 |
| 承認条件 | 分岐や複数段階を設計 | 複雑な承認条件に対応できるか要確認 | 代理承認などの対応範囲は製品による |
| 外部連携 | コネクタなどで接続 | 標準機能だけでは対応範囲が限られる | 連携機能や追加開発の条件を確認 |
| 費用の確認 | 利用権・追加ライセンス・構築費 | 既存契約と設定作業の範囲を確認 | 製品利用料・導入費・連携費 |
| 管理の負担 | 接続・実行・変更の管理が必要 | 承認者・権限・操作ルールを管理 | 組織情報・設定・保守契約を管理 |
| 選ぶ前の確認 | 実行制限とエラー時の対応 | 編集時の動作と履歴の扱い | 旧基盤への依存とデータの保存先 |
Power Automate｜Microsoft 365と連携して自動化
Power Automateでは、SharePointへの申請登録をきっかけに承認依頼を送り、結果をリストへ記録する流れを作れます。
OutlookやTeamsへの通知も設定できるため、Microsoft 365を日常的に使っている企業では、普段の業務環境を活かして申請・承認を自動化できます。
金額に応じた承認ルートや、期限が近づいた申請への通知なども、業務に合わせて設定しましょう。
ただし、旧フローをそのまま読み込むだけで移行が終わるとは限りません。
連携先や実行方法によって必要なライセンスも変わります。
まずはよく使う申請業務のフローを試作し、利用者が操作しやすいか、担当者が管理できるかを確かめてください。
SharePointの標準機能｜簡単な承認業務に対応
SharePoint Onlineのリストや文書ライブラリでモダン承認を有効にすると、項目やファイルの承認依頼と結果確認ができます。
複雑な振り分けが不要な業務なら、独自のフローを作る前に標準機能を試すとよいでしょう。
一方で文書の公開可否を管理するコンテンツ承認は、モダン承認と別の機能です。
内容を確認してもらいたいのか、承認前の文書を他の社員に見せたくないのかによって、使う機能を選びましょう。
また、モダン承認では処理中の項目を変更すると承認が取り消されるなどの制約があります。
承認依頼を送っても、対象項目の閲覧権限は自動で付与されないので、承認者の権限も確認しましょう。
専用ワークフロー製品｜複雑な申請・承認に対応
何段階もの承認や代理承認、組織変更への対応が必要な企業では、専用製品も選択肢の一つです。
必要な申請フォームや履歴管理の機能が揃った製品なら、独自に開発する作業を減らせる場合があります。
ただし、標準で対応する機能は製品ごとに異なります。
差し戻し後の再申請や監査用の記録出力など、実際の業務手順に沿って操作を試し、比較することが大切です。
SharePointとの連携方式、データの保存先、旧ワークフローへの依存も確認してください。
ポータルに申請先をまとめられるか、利用者が迷わず操作できるかも確かめましょう。
業務要件・費用・運用体制で比較する
まず、申請から完了までに必要な処理を書き出し、必ず必要な機能と、運用方法の変更で対応できる部分を分けましょう。
承認者の人数だけでなく、金額による分岐、代理承認、添付資料、履歴の保管なども比較項目です。
初期構築費、月々の利用料、保守費を含め、同じ利用人数・処理量・利用期間で総額を比較しましょう。
あわせて、設定変更や日々の管理にどれだけ手間がかかるかも確認してください。
申請する社員と管理する担当者の両方に操作してもらうと、使いにくい箇所がわかります。
導入後に誰が修正や動作確認を行うかも決めた上で、移行先を選んでください。
製品ごとの特徴や選び方については、ワークフローツールおすすめ8選【Microsoft 365での構築方法も解説】という記事で詳しく解説しています。
Power Automateへの移行を進める5ステップ
Power Automateへの移行は、次の5つのステップで進めましょう。
- 既存ワークフローと対象業務を棚卸しする
- 移行するフローと優先順位を決める
- 承認ルートとデータ連携を設計する
- フローを構築して動作を検証する
- 本番運用へ切り替えて利用者に周知する
ここでは、上記5つのステップについて詳しく解説します。
なお、部署ごとの申請方法や閲覧できる情報を整理し、業務に支障が出ないよう社内ポータルサイトを改修するには、SharePointの構成や権限設計に関する知識も必要です。
自社での対応が難しい場合は、SharePointに詳しい専門家へ相談するのも一つの方法です。
私たち株式会社BITSCRATCHは、SharePoint Onlineの社内ポータル構築・運用を支援しています。
エンジニア、デザイナー、解析担当が連携し、画面の構成や使いやすさを検討します。
申請フォームが見つからない、情報が部署ごとに分散しているといったお悩みもご相談ください。
公開後のアクセス解析や改善も支援しています。
構築後の更新や管理に不安がある方も、支援内容についてお気軽にご相談ください。
移行に伴うポータルの改修範囲を整理したい方は、まずは無料のサービス資料をご覧いただくか、お問い合わせフォームからお気軽にご相談ください。
1）既存ワークフローと対象業務を棚卸しする
申請名、保存先、利用部署、開始条件、承認者、連携先を一覧にまとめましょう。
設計書にあるフローだけでなく、現場が実際に使うフォームや通知メールも確認する必要があります。
金額による分岐や、担当者不在時の対応など、通常の申請では見えにくい条件も記録してください。
旧フローの情報を取得できない場合は、申請者と承認者へ聞き取りを行い、業務の流れを再整理します。
処理件数や未完了の件数、業務の締め日も記録しておくと、対応する順番を決める際に役立ちます。
ポータルのリンク先も確認し、どの画面から申請するかを一覧にまとめてください。
2）移行するフローと優先順位を決める
棚卸しした業務を、継続するもの、手順を簡素化するもの、廃止するものに分けましょう。
使われていない申請や重複した承認を整理すると、新しいフローの構築と保守の負担を減らせます。
優先順位は利用件数だけでなく、支払いや契約への影響、一時的な対応にかかる手間も含めて判断しましょう。
旧ワークフローの廃止で止まった業務は、早めに代替手段を用意する必要があります。
移行担当者と業務責任者で、どの業務を移し、何を確認したら移行完了とするか決めてください。
まず一つの業務で動作を確かめ、見つかった問題を他のフローの設計にも反映すると、同じ修正を繰り返さずに済みます。
3）承認ルートとデータ連携を設計する
金額や部署で承認者が変わる条件を整理し、誰がどの順番で判断するか決めましょう。
承認だけでなく、却下、差し戻し、取り下げ、代理対応のルールも必要です。
承認者をフロー内で直接指定するか、管理用リストから取得するかによって、人事異動時に変更する箇所が変わります。
外部システムと連携する場合は、受け渡す項目と失敗時の扱いを先に確認してください。
申請番号でデータを結び付けると、システム間で処理状況を確認しやすくなります。
申請者と承認者が閲覧できる情報も整理し、接続に使うアカウントへ適切な権限を設定します。
4）フローを構築して動作を検証する
まずよく使う申請を選び、申請の受付から承認依頼、結果の記録、通知までの流れを作りましょう。
承認された場合だけでなく、却下や期限切れ、承認者の不在、接続エラーが起きた場合の動きも確認してください。
金額で承認先が変わる場合は、切り替わる金額の前後を試しましょう。
複数の申請が同時に届いた場合や、添付資料がない場合も確認が必要です。
リスト更新でフローが繰り返し起動しないか、通知が重複しないかも確認項目です。
申請者と承認者には実際の権限で操作してもらい、見え方を確かめましょう。
テスト結果と修正内容を残し、業務責任者に実際の手順と合っているか確認してもらった上で、本番へ切り替えてください。
5）本番運用へ切り替えて利用者に周知する
切り替え日、対象業務、未処理申請の扱いを決め、利用部署へ事前に伝えましょう。
旧基盤が停止済みなら、暫定の台帳やメールから新しい申請先へ切り替える手順を整理します。
社内ポータルサイトのリンク、操作説明、問い合わせ窓口を同時に更新してください。
旧申請を新しいフローへ登録し直す場合は、申請番号を照合して二重処理を防ぎます。
公開直後は申請件数と完了件数、エラー通知を確認しましょう。
問題があればすぐに対応できる担当者も決めておいてください。
利用者には変更点を絞って案内し、問題が発生した際の代替手順も共有して、業務の中断を抑えます。
移行にかかる費用・期間と押さえたい5つの注意点
ワークフローの移行では、フローを作り直すだけでなく、ライセンスや権限、運用方法の見直しにも費用と時間がかかります。
移行にかかる費用・期間を見積もり、導入後のトラブルを防ぐために、次の5つの注意点を確認しましょう。
- 既存フローをそのまま移せるとは限らない
- 必要なライセンスと追加費用を確認する
- 接続アカウントとアクセス権限を確認する
- 処理時間・実行回数などの制限を確認する
- 承認履歴の保存とエラー時の対応を決める
ここでは、移行費用・期間を左右する条件と、上記5つの注意点について詳しく解説します。
移行費用・期間を左右するフローの数と複雑さ
単純な通知と、複数部署をまたぐ稟議では、同じ1本のフローでも作業量が異なります。
費用の見積もりには、調査、設計、構築、テスト、履歴整理、利用者への説明を含めましょう。
承認条件の整理や現場での確認にも時間がかかるので、フローの本数だけでは必要な期間を見積もれません。
まず代表的なフローを選び、要件と検証範囲を決めて見積もりを取ってください。
ポータル改修を含める場合は、ワークフロー単体の費用と分けて確認します。
社内担当者への聞き取りやテストの日程も、あらかじめ確保しておきましょう。
1）既存フローをそのまま移せるとは限らない
旧基盤とPower Automateでは、処理の組み方や使える機能が異なります。
既存の設定をコピーするだけでは、承認の流れやデータの扱いを再現できない場合があります。
独自の処理や外部製品を使っている部分は、代わりの機能や別の接続方法で対応できるか検討してください。
SharePoint Serverからワークフローを移行する際は、移行対象がツールの対応範囲に含まれていれば、SharePoint Migration Tool（SPMT）を利用できる場合もあります。
ただし、このツールではワークフローの履歴データは移行対象に含まれません。
必要な承認や通知、記録の保存ができるかを確認してください。
使われていない条件分岐や、現在の規程に合わない承認ルートも見直しましょう。
申請中の案件や過去の履歴については、新しいフローへ引き継ぐ情報と、記録として保存する情報を分けて整理します。
2）必要なライセンスと追加費用を確認する
Microsoft 365の対象ライセンスには、標準コネクタを使うPower Automateの利用権が含まれます。
ただし、プレミアムコネクタや一部の高度な機能には、追加のライセンスが必要です。
コネクタは、SharePointや外部サービスとデータをやり取りする接続機能を指します。
必要な契約は接続先だけでなく、自動実行か手動実行か、誰が利用するかでも変わるので、構成を決めてから確認しましょう。
月額利用料のほか、構築費、保存容量の追加にかかる費用、保守費も予算に含めてください。
契約前には最新の公式価格と利用条件を確認し、想定する人数で計算します。
最新の金額はPower Automate公式価格ページで確認できます。
3）接続アカウントとアクセス権限を確認する
フローの所有者と、SharePointやメールへ接続するアカウントを確認しましょう。
担当者の退職やアカウントの無効化で接続が使えなくなると、申請処理が止まる可能性があります。
共同所有者を設定するだけで、すべての接続が引き継がれるとは限らないので、接続の変更手順も残してください。
また、承認依頼を受け取った人が、対象の文書や申請を閲覧できるかも重要です。
操作に必要な権限を確認し、過剰なアクセスを与えないように設計しましょう。
管理用アカウントを使う場合も、契約条件と社内の認証・管理方針に沿って運用します。
4）処理時間・実行回数などの制限を確認する
Power Automateのクラウドフローは、承認待ちを含め、1回の実行期間が原則30日です。
長期間の稟議を1回の実行で待ち続ける構成では、期限切れへの対応が必要になります。
申請の状態を保存し、処理を分ける方法などを検討しましょう。
また、フローで行う処理の数や、連携先への接続回数にも制限があるので、申請件数だけでは負荷を判断できません。
1件の申請でも、データの確認や更新、失敗した処理のやり直しで処理回数が増えるので、申請が集中する時間帯の動作を確かめてください。
利用するライセンスとコネクタの制限を確認し、処理が遅れたときの通知先や再実行の方法も決めておきましょう。
5）承認履歴の保存とエラー時の対応を決める
承認者、判断日時、結果、コメントをどこへ保存するか、運用開始前に決めましょう。
Power Automateの実行履歴には保存期間の制限があります。
監査などで長期間保管する必要がある記録は、実行履歴とは別に保存しましょう。
保存期間と閲覧・変更権限を定め、申請番号で元の文書と結び付けてください。
エラー時は、誰に通知し、どこから再開するかも整理します。
そのまま再実行すると、同じ通知を送ったり、外部システムへ二重に登録したりする場合があります。
処理済みか確認する仕組みと、未完了の申請を確認できる台帳を用意して、対応漏れを防ぎましょう。
SharePointとPower Automateで承認フローを作成する方法
SharePointとPower Automateを組み合わせると、リストに登録した申請の承認依頼から、結果の記録・通知までを自動化できます。
承認フローの作成から他の業務への展開まで、次の4つのポイントを押さえましょう。
- 申請用のリスト・文書ライブラリを用意する
- フローの開始条件と承認者を設定する
- 承認結果を記録して申請者へ通知する
- テンプレートを活用して他の業務へ展開する
ここでは、上記の手順と、他の業務へ展開する際のポイントを解説します。
申請フォームの準備からPower Automateとの連携までの具体的な手順については、「SharePointで承認ワークフローを作る方法【申請フォーム作成からPower Automate連携まで徹底解説】」という記事で詳しく解説しているので、あわせてご覧ください。
申請用のリスト・文書ライブラリを用意する
金額や部署などの項目で申請を管理するならリスト、ファイルを中心に扱うなら文書ライブラリを用意しましょう。
申請番号、申請者、申請日、承認者、処理状況、結果など、業務で使う情報を整理します。
申請者や承認者にはユーザー列、金額には数値列を使うと、フローで承認先や条件を指定しやすくなります。
下書きと申請済みの状態を分け、未入力のまま承認依頼を送らない設計も必要です。
添付資料の保存先と閲覧権限を確認してください。
検証では実際の個人情報を使わず、サンプルデータで画面や更新処理を確かめましょう。
その結果をもとに、利用部署の担当者と相談して入力項目を調整します。
フローの開始条件と承認者を設定する
Power Automateで、SharePointへの項目登録などを開始条件に設定しましょう。
登録直後に承認を始めるか、申請済みへ状態が変わったときに始めるかは、入力の流れに合わせて選びます。
次に、承認依頼を送って回答を待つアクションを追加し、承認者、申請内容、対象項目へのリンクを設定してください。
承認を依頼する人が複数いる場合は、全員の承認が必要か、誰か1人の承認でよいかを決めます。
更新を開始条件にする場合は、フローによるリスト更新で同じ処理が繰り返されない条件を設けましょう。
金額などで承認先を変える場合は、条件ごとの処理を追加してください。
承認先が切り替わる金額の前後や、承認者が登録されていない場合も動作を確かめましょう。
承認結果を記録して申請者へ通知する
承認アクションの結果に応じて処理を分け、リストへ承認済み・却下などの状態を書き込みましょう。
回答者、回答日時、コメントも残すと、担当者が判断の経緯を確認しやすくなります。
複数の承認者がいる場合は、各人の回答を記録する処理も設計しましょう。
その後、申請者へメールやTeamsで結果と次の手続きを案内してください。
申請時の内容と承認対象の文書が一致しているかを確認できる記録も必要です。
承認後の編集を許可する場合は、再承認の条件を決めましょう。
承認結果の保存に失敗した場合に、完了通知だけが送られてしまわないよう、処理の順番とエラー時の動作も確かめてください。
テンプレートを活用して他の業務へ展開する
Power Automateのテンプレートを使うと、よくある承認処理の構成を参考にできます。
ただし、接続先のリストや承認者を変えるだけで、別の業務へそのまま適用できるとは限りません。
保存する項目、開始条件、権限、通知内容を業務ごとに確認しましょう。
共通の設計書とテスト項目を用意すると、他の業務に使う際の確認漏れを減らせます。
承認者の一覧や通知文は、更新する場所と担当者を決めておくと管理しやすくなります。
完成したフローは変更日と担当者を記録し、検証用と本番用を区別してください。
使う部署を少しずつ増やし、寄せられた問い合わせをもとに説明や設定を見直しましょう。
ワークフロー移行とあわせて見直したい社内ポータルサイトの4つのポイント
新しいフローが動いても、申請先や処理状況を確認する画面が見つからなければ、利用者の手間は残ります。
ワークフローの移行にあわせて、社内ポータルの次の4つを見直しましょう。
- 申請先を迷わず見つけられる導線
- 申請・承認状況を確認しやすい画面
- 業務に合ったリスト構成とアクセス権限
- 担当者が変わっても運用できる管理体制
ここでは、上記4つのポイントについて詳しく解説します。
1）申請先を迷わず見つけられる導線
部署名やシステム名だけで分類するより、経費を申請する、休暇を届け出るなど、利用者の目的で入口を整理しましょう。
よく使う申請へのリンクは、トップページから少ない操作でアクセスできる場所に配置し、必要書類や申請期限もあわせて掲載します。
旧フォームへのリンクが残ると迷いや重複申請につながるので、関連ページと検索結果も確認してください。
似た名前の申請には、どのような場合に使うか説明を添えてください。
部署によって見える申請が異なる場合も、権限設定を含めて検証します。
初めて使う社員に操作してもらい、申請先へたどり着けるか確かめましょう。
2）申請・承認状況を確認しやすい画面
自分の申請と、自分が承認する案件を分けて表示すると、利用者が必要な情報を探しやすくなります。
申請日、処理状況、現在の担当者、期限などを一覧で確認できる構成を検討しましょう。
承認待ち、差し戻し、完了などの表示は、部署ごとに表現がばらつかないように揃えます。
色に加えて、承認待ちや完了などの文字も表示してください。
申請番号も表示しておくと、問い合わせの際に対象の申請を特定しやすくなります。
ただし、画面で項目を絞り込むだけではアクセス制限になりません。
閲覧権限を別に設定し、閲覧を許可していない社員にも申請内容が表示されてしまわないか確認する必要があります。
3）業務に合ったリスト構成とアクセス権限
入力項目が多すぎると、申請者も確認する担当者も負担を感じやすくなります。
必須項目と参考情報を分け、金額や部署名の入力方法も揃えておきましょう。
添付資料と申請を結び付けるには、申請番号などを使います。
権限は、申請者、承認者、管理者が何を閲覧・編集できるかを基準に設計してください。
人事情報や契約資料を扱う場合は、別の保存先へ分ける選択肢もあります。
部署変更や退職で権限が残らないよう、見直しの手順を用意しましょう。
リストの構成とアクセス管理を一緒に決めると、後からの修正を減らせます。
4）担当者が変わっても運用できる管理体制
フローの構成、接続先、権限、変更方法を文書にまとめ、複数の担当者が参照できる場所へ保存しましょう。
設定内容を担当者だけが把握していると、異動後に修正できなくなるおそれがあります。
日常の更新と技術的な障害への対応について、それぞれの担当者と問い合わせ先を決めてください。
承認者の変更やポータルのリンク更新も、実施手順と確認者を決めます。
定期的に申請件数やエラーを確認し、不要なフローを整理してください。
引き継ぎの際は、新しい担当者に手順書を見ながら操作してもらい、不明点がないか確かめましょう。
SharePointの移行・改修を専門会社に相談すべき5つのケース
次のような課題がある場合は、SharePointに詳しい専門会社への相談を検討しましょう。
- 廃止対象や影響範囲を把握できない
- 承認ルートや外部システム連携が複雑
- 社内に移行を担当できる人がいない
- 社内ポータルの使いづらさも改善したい
- 移行後の保守・運用まで支援が必要
移行に伴って社内ポータルも改修する場合は、申請先への導線や画面の使いやすさ、公開後の管理方法までまとめて相談するとよいでしょう。
私たち株式会社BITSCRATCHでは、SharePoint Onlineのポータル構築と公開後の運用改善を支援しています。
標準機能では難しいデザインや機能のカスタマイズに加え、公開後のアクセス状況をもとに、ページ内の案内やバナーの配置も見直します。
社内ポータルの構築・改修や公開後の運用にお悩みの方は、まずは無料のサービス資料をご覧いただくか、お問い合わせフォームからお気軽にご相談ください。
1）廃止対象や影響範囲を把握できない
複数部署が個別に申請を作っていると、管理者だけでは利用状況を把握しきれない場合があります。
外部製品が旧ワークフローを使っている場合もあるので、画面を見るだけでは判断できません。
専門会社へ相談する際は、サイトの一覧、申請フォーム、過去の設計書、停止している処理を共有してください。
どの環境を調べ、何を報告してもらうかを事前に決めると、調査の範囲が明確になります。
社内の業務担当者にも参加してもらい、システム上の設定と実際の手順を照合しましょう。
調査結果をもとに、どの機能を改修する必要があるか判断してください。
2）承認ルートや外部システム連携が複雑
金額や組織による分岐、複数人の同時承認、外部システムへの登録が重なると、設計と検証の負担が増えます。
通常の承認だけでなく、一部が失敗した場合や途中で申請を変更した場合の動きも決めなければなりません。
社内だけでは対応が難しい場合は、業務ルールと接続先の仕様を整理して専門会社へ相談しましょう。
依頼時には、利用する接続方式、追加ライセンス、重複登録の防止方法を確認してください。
ポータルの改修と外部連携の開発について、それぞれどこまで依頼するか決めておきましょう。
業務部門にも設計に参加してもらい、差し戻しや代理承認などの手順も確認してください。
3）社内に移行を担当できる人がいない
日常の問い合わせ対応を抱えながら、移行の調査やテストまで進めるのが難しい企業もあります。
承認ルールや優先順位を社内で決め、設計・構築・検証を専門会社に依頼する方法もあります。
専門会社には、自社の申請手順や利用者に知らせる変更点を伝えてください。
窓口と確認者を決め、打ち合わせやテストに参加できる時間を確保してください。
納品時には運用手順の説明と引き継ぎを依頼しましょう。
引き継ぎ後に社内で設定を変更できるよう、操作手順や変更時の注意点も確認しておきましょう。
4）社内ポータルの使いづらさも改善したい
申請先が部署ごとに分散し、社員から探し方の問い合わせが繰り返される場合は、画面構成も見直すとよいでしょう。
フローだけを作り直しても、古いリンクやわかりにくい分類が残ると、利用者の負担は解消しにくくなります。
専門会社へ相談する際は、申請画面にたどり着くまでの操作手順、よくある問い合わせ、利用が集中するページを共有してください。
見た目だけでなく、必要な情報へたどり着けるかを基準に改善案を比べます。
権限や検索、モバイルでの操作も確認項目に含めましょう。
移行と改修の対象を整理し、業務を続けながら段階的に切り替える計画を立てると進めやすくなります。
画面のレイアウトを検討する際は、「SharePoint社内ポータルサイトのデザイン事例【無料テンプレート22種類の特徴も解説】」という記事も参考にしてください。
5）移行後の保守・運用まで支援が必要
公開後も、承認者の異動や業務ルールの変更、接続エラーへの対応が必要です。
社内だけで監視や修正を続けるのが難しい場合は、保守・運用まで相談できる会社を検討しましょう。
契約前には、問い合わせの受付時間、対応する障害、変更作業の料金、緊急時の連絡方法を確認してください。
ポータルの保守に、Power Automateや外部システムの保守も含まれるか確認してください。
日々の更新は社内で行い、技術的な修正を外部へ依頼する方法もあります。
定期的にエラーや利用状況を確認し、設定や操作説明を見直す担当者も決めておきましょう。
構築後のサポートを含めた依頼先の選び方は、「SharePointサイト構築ベンダーのおすすめ5選【失敗しないための選び方も解説！】」という記事で詳しく解説しています。
SharePointワークフローの廃止に関するよくある質問
廃止対象を確認した後も、「旧フローを再び使えるのか」「追加のライセンスが必要なのか」といった疑問が残ることがあります。
ここでは、旧フローの再利用、移行先の選択、必要なライセンス、既存データの扱いについて、よくある質問にお答えします。
廃止されたワークフローを再び使う方法はありますか？
SharePoint Onlineでは、2013ワークフローを2026年4月2日以降も延長して使う選択肢はありません。
再び使えるようになるのを待つのではなく、Power Automateや別の承認手段への切り替えを進めましょう。
申請画面や設定が残っていても、SharePoint Onlineの廃止された旧基盤では処理を再開できません。
未完了の申請は業務担当者と確認し、対応状況を台帳などへ記録してください。
一方でオンプレミスは製品と実行基盤で条件が異なるので、Onlineの結論をそのまま当てはめないことが大切です。
サポートが終了した環境を使い続ける場合は、環境自体の更新も検討します。
Power Automateへの移行は必須ですか？
Power Automateだけが移行先ではありません。
単純な承認ならSharePointの標準機能、複雑な稟議なら専用製品など、業務に合う手段を選べます。
Microsoft 365との連携が多いなら、Power Automateの機能と費用を確認してみてください。
必要な承認ができ、記録を残せるかに加え、担当者が管理を続けられるかも確かめましょう。
利用人数、連携先、管理者のスキル、費用を整理して比較してください。
業務によって異なる手段を使い分ける場合も、ポータルに入口と説明を集約すると、利用者が申請方法の違いで迷いにくくなります。
Microsoft 365の契約だけで承認フローを作れますか？
Microsoft 365の契約にPower Automateの利用権が含まれていれば、標準コネクタを使って承認フローを作成できる場合があります。
SharePointで受け付けた申請の承認やメール通知を行う場合も、使う機能が契約の範囲に含まれているか確認してください。
Microsoft 365を契約しているだけで、Power Automateのすべての機能が使えるわけではありません。
プレミアムコネクタやカスタムコネクタなどを使う場合は、追加契約が必要になることがあります。
必要なライセンスは、フローの実行方法や利用者でも変わります。
管理者に現在の契約を確認してもらい、使う機能を示した上で、追加費用の有無を判断しましょう。
SharePointのリストや文書も移行が必要ですか？
ワークフローの廃止だけを理由に、SharePoint Onlineのリストや文書をすべて移す必要はありません。
既存の保存先を使い、申請や承認の処理だけを新しい仕組みへ置き換えられる場合があります。
新しいフローの設計に応じて、状態や履歴の項目追加、権限の見直しが必要か確認してください。
旧フローのタスクや履歴、処理中の案件は、通常の申請データとは分けて扱います。
別製品への移行やポータルの再構成を行う場合は、保存先を変更するか検討してください。
文書のリンク、版、閲覧権限がどう引き継がれるかも確認し、利用者が必要な情報を探せる状態を保ちます。
SharePoint Designerで作ったワークフローは、廃止後どうなりますか？
SharePoint Onlineでは、Designerで作った2010ワークフローは2020年11月1日、2013ワークフローは2026年4月2日に廃止済みです。
Power Automateなどで作り直してください。
SharePoint Server（オンプレミス）でも、ワークフローは使えなくなりましたか？
SharePoint Onlineとは条件が異なります。
Subscription Editionでは、2010ワークフローのサポートが2026年7月14日に終了し、2013ワークフローは以降もサポート対象です。
ワークフロー廃止を機に使いやすいSharePoint社内ポータルを制作するなら株式会社BITSCRATCHへ
ワークフローを移行する際は、申請・承認の仕組みに加えて、社内ポータルの案内も見直すことが大切です。
新しいフローが動いていても、申請先が見つからなかったり、古い操作説明が残っていたりすると、社員が迷う原因になります。
私たち株式会社BITSCRATCHは、SharePoint Onlineの社内ポータル構築・運用を支援しています。
設計を担うエンジニア、画面を制作するデザイナー、利用状況を分析する解析担当が連携し、社員が必要な情報を探しやすく、担当者も更新しやすいポータルを提案します。
標準機能では難しい画面のデザインや機能の追加にも対応し、契約内容に応じて、月次レポートによる利用状況の確認やバナー制作も行います。
Power Automateのフロー移行や外部連携の開発もご希望の場合は、対応できる作業の範囲と費用、公開後のサポートについて個別にご案内します。
ワークフロー移行にあわせた社内ポータルの構築・改修にお悩みの方は、まずは無料のサービス資料をご覧いただくか、お問い合わせフォームからお気軽にご相談ください。
まとめ
SharePoint Onlineの旧ワークフローは廃止済みなので、対象業務と未完了の申請を確認し、代替手段へ切り替える必要があります。
移行先は承認ルール、費用、運用体制で比較しましょう。
履歴の保存や権限、エラー時の対応まで設計すると、移行後の管理を続けやすくなります。
申請の入口となる社内ポータルも見直し、社員が迷わず使える環境を整えてください。