Why Is Salesforce Flow Making Its Way Out of the Setup Menu?
自動化の歴史におけるセットアップの役割
Flow アプリの現在のリビジョンはSpring '19から登場したばかりですが、Salesforce アプリケーションには数十年前から複数の自動化ツールが存在していました。Flow は近年、自動化ツールの定番となり、ワークフロールールとプロセスビルダーはFlow に統合されました。これらのツールは、Apex や Visualforce と共に、これまでずっと設定メニューに常駐していました（必ずしも「自動化ツール」に分類されるわけではありませんが、Flow などのツールと同様の機能を実行します）。
自動化アプリ
Summer '24では、設定メニューからフロー自動化を利用できる新しい機能「自動化アプリ」が導入されました。Salesforceプロフェッショナルが設定メニューから離れたネイティブ自動化ツールを構築、監視、管理できるのは、今回が初めてです。
専用アプリケーションの利点は、Lightning アプリケーション ビルダーを使用してホームページを編集できること (技術的には、 Flows アプリケーション内に画面フローを埋め込むことができます。メタですね!) と、セットアップ メニューでは利用できないリスト ビューの機能を利用できることです。
右下には、エラーが発生したフローを表示するセクションがあります。ユーザーはこの情報を大まかに把握し、必要に応じて対処することができます。また、「Flow App Home Cards」と呼ばれるコンポーネントもあり、Flow についてさらに詳しく知ったり、Flow/Trailblazer コミュニティに参加したりするための情報を提供します。
自動化によってシステム内のすべてのフロー自動化が統合されましたが、これは設定メニューにどのような影響を与えるのでしょうか？設定メニューは徐々に複数のLightningアプリに置き換えられていくのでしょうか？幸いなことに、承認プロセスなど、設定メニューに残しておくべきクラシック機能がいくつかあります。しかし、ちょっと待ってください…
承認アプリ
承認プロセスは、長らく機能強化が切実に求められてきました。ワークフロールールと承認プロセスはクラシックスタイルのインターフェースを共有しており、ワークフロールールは一度ならず二度も（ワークフロールールからプロセスビルダー、そしてフローへと）同時に置き換えられました。
長年の不足の後、ようやくSpring '25でフロー承認の形で承認プロセスが更新されました。
承認は、Salesforce Summer '25 で提供されたフロー承認の新しいホームです。フロー承認を一元管理できる「フロー承認プロセスを作成」ボタンがあり、このボタンをクリックすると、フロー承認の新規作成プロセスをガイドする、非常に重要な新しいウィザードが開きます。
承認は通常のフローとはまったく異なる機能であるため、Salesforce が承認を独自のアプリに組み込むことはある程度理にかなっています。しかし、承認アプリの名前を単に「フロー」に変更する必要があるかどうかという疑問が生じます。
セットアップにおけるフローの未来
これはエンドユーザートリガーフローのようなものの始まりになるのではないかと推測しています。ユーザーが定期的に実行したい一連のアクション（例えば、リードを特定のステータスに設定する、指定期間内にフォローアップするタスクを作成する、Slackチャンネルにテンプレート化された更新を送信するなど）のようなもので、必ずしもすべてのレコードに適用する必要はありません。
このような機能には一定の価値があると思いますが、同時にミスが発生する可能性も大きくあります。ご存知の通り、大きな力には大きな責任が伴います。この機能は、エンドユーザーに制御不能なほど大きな権限を与えることになり、組織を管理する管理者にとって多くの問題を引き起こす可能性があります。
憶測はさておき、自動化アプリと承認アプリは現在、現状のまま存在しています。Salesforceの最近の動きには、いくつかの疑問が浮かび上がります。
- Flow はセットアップ メニューから削除されますか?
- セットアップ メニュー全体をさまざまなセットアップ アプリに置き換えるという長期的な計画はありますか?
- Flow Orchestratorはどうですか？タブはありますが、アプリはどうですか？
- リスト ビューがセットアップ メニューに直接追加されないのはなぜですか?
現時点では、これらすべての質問に対する明確な答えがあるとは思えません。おそらく、Flow とセットアップ メニューの将来がどうなるかは、待って見守る必要があるでしょう。
個人的には、設定メニューを分割するというアイデアには反対しませんし、Salesforceの最近の取り組みとも合致していると思います。Salesforceは最近、サービス設定など、様々な設定メニューを導入してきました。特定のアプリへの対応は、この進化における自然な流れと言えるかもしれません。
まとめ
管理者主導の自動化が設定メニューのみに存在していた時代は完全に終わりました。自動化アプリと承認アプリは、Lightningアプリ内でこれらの機能を新たに提供し、より多くのカスタマイズと、時間の経過とともに新しいメインアプリケーション機能のサポートを可能にします。
より幅広いコミュニティの皆様と議論を深めたいと思います。Salesforce Flow と設定メニューの将来について、皆様はどうお考えでしょうか？設定メニュー全体についてはどうお考えでしょうか？このまま維持していくべきでしょうか、それともドメイン固有の設定アプリに置き換えるべきでしょうか？設定メニューの他の部分で、Lightning アプリの活用が効果的だと思われるものはありますか？
Einstein for Flow が一般公開されました: チュートリアルと最初の手順
Spring '25は、Salesforce Flowを究極の自動化ツールにするというSalesforceのコミットメントを示す、またしても新たなリリースとなりました。Salesforceのプロフェッショナルが、最も複雑なビジネスプロセスにも対応できるよう、すぐに使える機能がさらに充実しています。ベータ版期間を経て、Einstein for Flowが一般提供となり、Salesforceチームが自動化を作成・文書化できるようカスタマイズされています。
この記事では、Einstein for Flow の使用を開始する方法と、この機能が Salesforce 管理者としての日常業務にどのように役立つかを詳しく説明します。
Flow で Einstein を有効にする
Einstein for Flowは設定から簡単に有効化できます。Einstein Generative AIがセットアップされたことを確認したら、専用の「Einsteinを使用したフロー作成」ページからEinstein for Flowを有効にすることもできます。
権限の観点から言えば、フロー管理権限が必要です。また、Einsteinでフローを作成すると生成AIが使用され、 Einsteinリクエストが消費されるため、デジタルウォレットの使用量に注意してください。
有効にすると、Flow Builder内にEinsteinボタンが表示されます。右側にはプロンプトがドッキングされており、ボタンで切り替えることができます。新しいフローを作成する際に、「Einsteinで構築を支援」オプションが表示されます。
自動化するプロセスを知る
Flow Builder に進む前に、何を自動化しようとしているのか、また、オブジェクト、フィールド、アクション、受信者など、自動化における主要な役割を理解することが非常に重要です。
全体的なプロセスに関しては、いつトリガーするか、どのような基準を考慮するか、更新や計算を実行する必要があるかどうかを把握しておく必要があります。
また、現時点では Einstein for Flow は最大約 6 要素までのフローを作成できるため、プロセスをこれよりも複雑にする必要がある場合は、最初に Einstein でフローを生成し、その後、その上に構築してプロセスを高速化することができます。
この機能は、最終的にはできるだけ多くの時間を節約することを目的としており、Spring '25 リリースではベータ版と比較してすでに高速化と精度が向上していますが、今後さらに改善されていくことは間違いありません。
Einsteinがフローを構築します
Einstein for Flow は、入力した自然言語プロンプトに基づいてフローのドラフトを作成することで、Salesforce Flow を使用して自動化を構築する Salesforce プロフェッショナルの時間を節約することを目的としています。
指示は具体的に記述し、プロセス内で使用されるオブジェクトとフィールド、そして必要に応じてその他の設定も含める必要があります。例えば、フローで特定のユーザーにのみメールを送信する場合は、送信基準と、本文に含めるメッセージやレコード情報を必ず明記してください。
Einstein for Flow のご利用を選択すると、すぐに使える4つのサンプルプロンプトが組み込まれています。その他のサンプルについては、こちら をご覧ください。
この例では、すぐに使用できるプロンプトを選択し、Einstein にフローのドラフトを作成させる前に、もう1文の指示を追加しました。この場合、新しい取引先責任者レコードが作成されるたびに、レコードトリガーフローによって取引先所有者にメール通知が送信されるように設定しています。メール本文には、取引先責任者名、メールアドレス、取引先名を取引先所有者に通知する必要があります。
このシンプルな例は、約1分で生成されました。Einstein が完成したら、ドッキングされたプロンプト内で確認とフィードバックを行ってください。必要に応じて、指示を編集することもできます。結果が期待どおりでない場合は、最初からやり直すこともできます。
レビュー、テスト、そして構築の継続
Einstein for Flow は、Flow に関する広範な知識の代替として考えるべきではありません。最終的には、プロセス、ベスト プラクティス、自動化の実行内容について理解している必要があるためです。
上記の AI 生成フローは、連絡先が関連付けられているアカウント ID が実際に存在することを確認した後、連絡先が作成されるたびに開始されます。
デフォルトでは、取引先責任者を作成する際に取引先は必須ではありません（開発者エディションなど）。取引先の情報はフローの後半で使用されるため、Einsteinによって追加されたエントリ条件は保証されます。また、フローはメール通知を送信する必要があるため、アクションと関連レコードに最適化されています。
このフロー内の 1 つの要素は、電子メールを送信するアクションであり、これは Einstein に提供されたプロンプトに基づいて構成されます。
正しい受信者が選択され、EmailBody のアクションでテキスト テンプレート リソースが正しく使用され、件名が入力されましたが、リソースを詳しく調べたところ、いくつかの編集が必要であることがわかりました。
EmailBody Text Templateを拡大表示すると、プロンプトで言及されているリソース（それぞれ連絡先名とアカウント名）は含まれていますが、連絡先メールアドレスは含まれていません。これはプロンプトで「連絡先メールアドレス」の入力を求められていることが原因だと考え、指示を編集してフィールド名を正確に「連絡先メールアドレス」に変更しました。しかし、それでも追加されませんでした。
さらに、テキスト テンプレートでは引用符とアンパサンドの使用は不要です (数式では必要)。そのため、電子メール出力でもこれらの文字が公開されることになり、理想的ではありません。
テキストテンプレートに変更を加える前にフローをテストすると、メール通知に以下のメッセージが含まれます。テキストテンプレートを少し調整するだけで、アクションは使用できるようになります。
Einsteinによって生成されたフローに加え、既存のフローと同様に編集を続け、必要に応じて要素や機能を追加できます。また、下書きは自動的に保存されないため、作業の進捗状況を失わないように、必ずフローを保存してから変更やデバッグを続行してください。
数式リソースにEinsteinを使用する
上のスクリーンショットで、Einstein for Flow によって EmailBody テキスト テンプレートの上に別のリソース (frmEmailMessageBody という数式) が作成されたことに気付いたかもしれません。
開く前は、両方の名前が電子メールの本文を参照していることを考えると、両方のタイプのリソースが同じ目的で生成され、アクションで数式またはテキスト テンプレートのどちらを使用するかをユーザーが選択する必要があるという印象を受けましたが、実際はそうではありませんでした。
下記のように、この数式は実際には作成された連絡先のURLです。ただし、これはテキストテンプレートには追加されておらず、リソースとして作成されたものです。ユーザーがレコードを開くためのメール通知にレコードURLが記載されていると便利ですし、数式の出力は正常に機能していました。しかし、プロンプトではこのURLの入力を求められていませんでした。
Spring '25 リリース以降、フローが AI によって生成されたかどうかに関係なく、数式フィールドで何を実行するかを記述して生成 AI を活用するのと同じように、Einstein を使用して個々の数式リソースの数式を自分で生成できます。
数式に名前を付け、種類を選択したら、Einsteinのサイドボタンをクリックすると、数式が実行する処理を自然言語で指示できます。これは商談レコードのフローで、ステージに基づいてテキスト数式を作成したいと考えていました。指示を記述する際は、以下に示すように、数式が参照するリソースを使用する必要があります。
Salesforce の専門家は、商談ステージが標準の選択リスト フィールドであることを知っていますが、フィールドが選択リストであるという事実がプロンプトに示されていなかったため、Einstein は当初戸惑いました。
以下は私が最初に使用したプロンプトです。この結果、式に誤りがあり、構文チェックでエラーが発生しました。繰り返しになりますが、このような結果を避けるため、指示は可能な限り詳細に記述してください。
説明を生成する
最後に、Flow Builder における Einstein のもう一つの用途は、単純なフローから複雑なフローまで、フローの説明を生成することです。このSpring '25 の新機能により、Salesforce の担当者は、フローが何を実行しているか、他のユーザーがフローを作成したときにどの項目が使用されているかを迅速に把握したり、新しいフローの作成時にその説明を自動的に生成したりできるようになります。
この例では、商談レコードをトリガーとするシンプルなフローを使用しました。このフローは、商談が成立すると完了日を今日の日付に更新します。ドッキングされたプロンプト内の「フローの要約」ボタンをクリックすると、Einstein がフローの概要を生成し、要素とアクション、使用されたオブジェクトと項目が反映されます。
フィードバックを再度提供したり、要約をコピーしたり、フローの説明に直接追加して必要に応じて編集したりできます。さらに、説明の長さを調整することもできます。より長いバージョンやより短いバージョンをご希望の場合は、調整も可能です。
このフローは、条件要件を満たすようにレコードが更新された場合にのみ実行されるように設定されていることに注意してください。しかし、AIの概要には「このフローはセグメントを公開せず、基準を満たすためにレコードの変更を必要としません」と記載されています。実際には、開始要素に記載されているように、基準を満たすにはレコードの変更が必要です。
考慮事項と制限事項
Einstein をフローや数式作成に使い始める前に、新機能の使用を開始する際と同様に、考慮事項と現在の制限事項をよくご確認ください。考慮事項には以下が含まれます。
生成 AI を活用するときは、応答が正確であり、組織の状況に適していることを確認してください。
- 生成AI機能を使用すると、本番環境とサンドボックス環境の両方でEinsteinリクエストが消費されます。詳細はこちらでご確認ください。
- 現時点では、スケジュールされたフローとレコードによってトリガーされたフロー、および自動起動フローと画面フローが Einstein for Flow によってサポートされています。
- フローと数式の作成はどちらも、ここで強調されているように、Salesforce 生成 AI プラットフォーム上のモデルをサポートしています。
まとめ
Einstein for Flow は、Salesforce プロフェッショナルによるフローの作成を効率化するだけでなく、自動化の文書化にも役立ち、既存のプロセスを理解する必要がある新しい管理者のオンボーディングにおいても大幅な時間の節約につながります。
既にEinstein 1をご利用の方は、ぜひこれらの新機能をサンドボックスで、新規または既存のSalesforceフローを使ってお試しください。