【Salesforce】Winter ’26に備えるフロー権限見直し入門|「動いていたのに使えない」を防ぐ 

目次

はじめに

「今まで普通に動いていた画面フローが、ある日突然ユーザーから開けなくなった」。
Winter ’26に向けて、そんなトラブルを防ぐために押さえておきたいのが、「フローを実行するためのユーザーアクセス権の制限(Restrict User Access to Run Flows)」 です。

このリリース更新が適用されると、これまで組織全体で暗黙的に実行できていたフローも、誰に実行権を与えるかを明示的に管理する必要があります。
特に、画面フローを業務画面やExperience Cloudで活用している組織では、事前確認が欠かせません。
Salesforceの公式ドキュメントでも、適用はWinter ’26に再スケジュールされたものの、今のうちに準備することが推奨されています。

Winter ’26で何が変わるのか

今回の更新の要点はシンプルです。

フローを動かせるユーザーを、プロファイルまたは権限セットで明示的に制御する方向に変わります。
あわせて、これまで一部のフロー実行を広く許可していた FlowSites組織権限は廃止 されます。

つまり、「今まで動いていたから大丈夫」ではなく、誰がどのフローを実行するのか を改めて整理する必要があります。
これはSalesforceの標準機能としてのセキュリティ強化であり、カスタム開発の有無にかかわらず影響し得る点が重要です。

影響を受けやすいフロー種別

Salesforceの公式ドキュメントでは、以下の種類のフローが影響対象として案内されています


画面フロー、Field Service Mobileフロー、連絡要求フロー、予定フロー、FieldServiceWebフロー

一方で、レコードトリガーフローやスケジュールトリガーフローなど、ユーザーが画面から直接起動しないフローは、このリリース更新の主な対象とはされていません。
ただし、最終的には自組織の利用状況に応じて動作確認することをおすすめします。

まず確認したい3つのポイント

影響対象の有無

まず確認したいのは、自社組織が本当に影響対象かどうかです。

Salesforce からは、影響が想定されるお客様に対してメール案内が送付され、その中で影響を受けるフローの定義 ID が案内されるケースがあると紹介されています。

ただし、「メールが来ていない = 影響なし」とは限らないため、[設定] – [リリース更新] 画面でも Restrict User Access to Run Flows の状態を確認しておくことが実務的には重要です。

実行権限の付与方法

対応の基本は、対象ユーザーに 「フローを実行」または「フローの管理」 の権限を付与することです。

運用上は、プロファイルに直接足すよりも、権限セットで役割ごとに管理する方法がメンテナンスしやすいケースが多いでしょう。
加えて、より細かく制御したい場合は、個別フローに対してプロファイルや権限セット単位でアクセスを絞る方法も案内されています。標準機能で一律に開放するのではなく、必要最小限で設計するのがポイントです。

ゲストユーザー・外部ユーザーの扱い

見落としやすいのが、ゲストユーザーやコミュニティユーザーです。

Salesforceの公式ドキュメントでは、ゲストユーザーやカスタマーコミュニティユーザーなどは、今後 FlowSites 権限を通じてフローを実行できなくなります。
もし該当するプロファイルがある場合は、どのフローにアクセスできるか適切な制御が行えるよう設定を見直す必要があります。

実務での見直し手順

フロー棚卸し

最初にやるべきは、どの部門がどの画面フローを使っているかの棚卸しです。
特に以下は優先確認がおすすめです。

・Experience Cloudで公開している画面フロー
・営業・サポート部門がLightningページから起動する画面フロー
・モバイルやField Service関連フロー
・サブフローとして呼び出される構成

サブフローについては、Salesforceは個別テストを特別推奨しておらず、親フローのアクセスルールがサブフロー側を上書きすると案内しています。親子構成を含めて整理しておくと、切り分けがスムーズです。

権限セット設計

次に、部門や業務単位で権限セットを整理します。
たとえば「営業向け画面フロー実行」「サポート向け画面フロー実行」のように用途別に分けると、後からの監査もしやすくなります。

ここで注意したいのが、フローの実行権限 と データ操作権限 は別物だという点です。
Salesforceの公式ドキュメントでも、ユーザーコンテキストで実行されるフローでは、実行ユーザーのプロファイルや権限セットによってオブジェクト権限や項目レベルセキュリティが適用されると説明されています。つまり、フローを開けても、参照・更新したい項目に権限がなければ処理は失敗する可能性があります。

Sandboxでの検証

本番で急に有効化するのではなく、Sandboxで対象ユーザーの権限を再現してテストするのが安全です。
確認したいのは次の3点です。

・フロー自体を起動できるか
・入力後にレコード作成・更新が成功するか
・外部ユーザーやゲスト経由の導線で問題が出ないか

Winter ’26のリリース更新は、準備期間を確保するために適用時期が後ろ倒しされています。逆に言えば、今のうちに検証しないと、本番適用時に影響が表面化しやすい更新でもあります。

見落としやすい注意点

今回の更新で特に注意したいのは、「フローが見えない」のか、「フローは起動するが途中で失敗する」のかを分けて考えることです。
前者はフロー実行権限、後者はオブジェクト権限や項目権限、実行コンテキストの問題であることが多いため、切り分けを混同しないことが重要です。
標準機能の更新内容だけを追うのではなく、自社で作成したカスタムフローの実行導線まで含めて確認しておくと、問い合わせの増加を防ぎやすくなります。

公式仕様は今後更新される可能性もあるため、最終的には最新のリリースノートとヘルプを確認してください。

まとめ

Winter ’26に向けたフロー権限見直しは、単なる設定変更ではなく、フロー運用を“誰に何を許可するか”で整理し直す機会です。
特に画面フローや外部公開導線を使っている組織では、事前の棚卸しと権限セット設計が重要になります。

「自社のどのフローが影響を受けるかわからない」「権限セットの切り方に迷う」といった場合は、運用設計とあわせて見直すのがおすすめです。もしご自身の会社はどうだろう?と疑問を持たれた方は、今回の記事の内容も参考にぜひ見直しを検討してみてはいかがでしょうか?

今回の記事はここまでとなります。最後までお付き合いいただき、ありがとうございました。
それでは、また次回の記事でお会いしましょう。

関連記事

目次