1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Salesforce Winter '27対応 | レコードトリガー・スケジュール・画面フロー・承認プロセスの実装ポイントまとめ

1
Posted at

はじめに

Winter '27でFlow Builderに追加された要素や設定は、地味に実装の組み方を変えるものが多いです。

新しい分岐要素、画面フローのリストビュー一括起動、承認プロセスのUI改善。

この記事では、レコードトリガーフロー・スケジュールフロー・画面フロー・フロー承認プロセスの4領域について、実装時に押さえておきたいポイントを整理します。

レコードトリガーフローの変化

分岐の選択肢が「決定」要素だけじゃなくなった

これまでレコードトリガーフローで条件分岐を作るときは、決定要素一択でした。Winter '27では、項目値による分岐 と 日付で分岐という2つの新しい分岐要素が追加されています。

「項目値による分岐」は、要するに「値ごとに専用レーンを作れる分岐」です。取引先責任者のステータスごとに処理を変えたいときなど、値の種類が決まっている場面で使うと組み立てがすっきりします。

「日付で分岐」は、フローが実行された日付を基準に枝分かれさせる要素です。指定日より前か後か、範囲内かを判定できて、日付は変数や数式でも指定できます。

正直、この2つを見たときは「決定要素で十分では」と思ったのですが、値の種類が多い分岐を組んだことがある人ならわかると思います。ブランチの数だけ条件文を書く手間が、これでかなり減ります。ただし複数の値を1つの経路にまとめたいケースは、まだ決定要素のほうが早いです。用途によって使い分ける前提の機能だと理解しておくとよさそうです。

⚠️ 注意
執筆時点では「デフォルトの結果」の部分の分岐名を変えることができませんでした。「決定」要素でデフォルトの結果のラベル名をわかりやすく変えていた管理者にとっては気になるポイントかも知れません。

保存した時点でミスを教えてくれる

レコード作成要素で必須項目への代入を忘れていて、実行時に初めてエラーで気づく。この経験がある人は多いと思います。Winter '27では、保存時の検証パネルで必須項目の代入漏れを警告してくれるようになりました。固定文字列が対象項目の文字数上限を超えている場合も、同じく保存時に検知されます。

つまり、実行して初めて気づいていたミスの何割かは、保存した瞬間にわかるようになったということです。動的な変数の値までは検証できませんが、それでも地味にありがたい変更です。

レコードのロック待ちも自動でリトライ

UNABLE_TO_LOCK_ROWのエラーに悩まされた経験、ありませんか。Winter '27では、トランザクション(データベースへの一連の処理のまとまり、と考えてください)の開始時にレコードロックのエラーが起きると、フローが10秒待ってから自動的にもう一度実行してくれるようになりました。

これまでApexで自前のリトライ処理を書いていた部分を、標準機能に任せられる場面が増えそうです。

スケジュールフローの変化

レコードロックの自動リトライも効いてくる

先ほどトリガーフローのところで紹介したレコードロックの自動リトライは、スケジュールフローやスケジュールパスにも当然効いてきます。むしろ大量レコードを一括更新するスケジュールフローのほうが、他の処理とロックがぶつかる場面は多いはずです。バッチサイズの自動調整と合わせて、大規模データ処理の安定性という点で今回のリリースはしっかり力が入っていると感じます。

バッチサイズを自動で調整してくれる(対象外)

大量データを処理するスケジュールフローは、CPU時間やSOQLクエリ数といったガバナ制限(1回の処理でSalesforceが許容するリソースの上限、と思ってください)に頻繁に引っかかります。

Winter '27では、開始要素の設定を有効にしておくと、バッチ処理が制限に引っかかったときにバッチサイズを自動的に半分にして再試行してくれます。処理できるサイズが見つかるまで半分、また半分、と調整を繰り返し、そのサイズで残りを処理していく仕組みです。

ですがこの機能はリリース対象外となっていました。期待していた機能だけに少し残念です。

"This feature isn't quite ready yet, so we removed it for now."(この機能はまだ準備が十分に整っていないため、今回は削除されました。)

画面フローの変化

今回のリリースで一番テンションが上がったのが、正直この画面フローです。長年の要望がまとめて実装された印象があります。

リストビュー・関連リストから複数レコードを一括処理

これまで画面フローで複数レコードをまとめて処理しようとすると、1件ずつ実行するか、Apexで無理やり組むしかありませんでした。Winter '27では、リストビューや関連リストから最大2,000件のレコードを選択して、そのIDを画面フローに渡し、一括処理できるようになりました。

やり方はシンプルです。フロークイックアクションを作成して、リストビューボタンレイアウトや関連リストのページレイアウトに配置するだけです。選択したレコードのIDはidsという名前のテキストコレクション変数に自動で渡されます。関連リストから起動した場合は、親レコードのIDも一緒に受け取れます。

私もこの機能をクライアントから何度も相談されてきたので、素直に「やっと来た」という気持ちです。つまり、複雑なApexを書かなくても一括処理の画面フローが作れる、という理解でOKです。

実は前からidsという名称で変数を定義しておけば、リストビューのリンクボタンからレコードを選択して起動すると、レコードidをコレクションとして渡すことができていたのですが、これが正式サポートされたということになります。

試してみた

例えば取引先Idを取得して一覧を出す簡単な画面を作ってみます。


取引先オブジェクトにクイックアクションを設定します。

リストビューボタンレイアウトにクイックアクションを配置します。

リストビューでレコードを選択した状態でクイックアクションを呼び出します。

レコードIdが渡されて一覧表示できることが確認できました。

条件付き表示がリアルタイムに反応するようになった

同じ画面上のコンポーネントを参照する数式は、これまで条件付き表示のルールで正しく評価されないという制約がありました。正直、自分もここで何度もハマったことがあります。

Winter '27ではこの制約が解消されて、ユーザーが画面のコンポーネントを操作するたびに数式がリアルタイム(操作した瞬間に、という意味です)で再評価され、フィールドの表示・非表示が切り替わるようになりました。前の入力内容によって次の質問を出し分けるようなウィザード形式の画面フローを作っている人には、かなり大きい変更だと思います。

時刻を入力するための標準コンポーネントが登場

これまで時刻の入力は、ピックリストで時間帯を無理やり選ばせるような代替手段に頼るしかありませんでした。Winter '27で標準のTime(時刻)コンポーネントが追加され、サービス予約や来店予約のような時刻入力を素直に実装できるようになっています。許容する時間範囲や入力間隔の指定、エラーメッセージのカスタマイズにも対応しています。

フロー承認プロセスの変化

1つのコンポーネントで最大10個の承認プロセスを選べる

レコードページやExperience Builderサイトに配置できる「承認を要求」コンポーネントが、選択できる自動起動フロー承認プロセスの数を最大10個まで持てるようになりました。

金額規模や部門ごとに承認ルートを変えたい、というケースはよくあると思います。1つのコンポーネントに複数の承認プロセスを紐づけて、ユーザー側に選んでもらう設計が現実的な選択肢になりました。

承認者が次のワークアイテムに自動で進める

承認者が1件処理し終えたあと、これまでは一覧画面に戻って次のワークアイテムを探す必要がありました。「次の作業項目を自動的に開く」というオプションを有効にしておくと、承認処理が終わると同時に次のワークアイテムが自動で開きます。承認業務が集中する部署ほど、このクリック削減はじわじわ効いてくるはずです。

大量データ処理中でも承認プロセスが詰まりにくくなった

大量データロードのようなバルク処理は、レコード変更に紐づくプラットフォームイベントを大量に発生させます。これまではこのイベントが承認ステップ完了のイベントと同じチャネルに詰め込まれていたため、バルク処理中に承認プロセスの進行が滞留するという問題がありました。

Winter '27では、レコード変更イベントが専用チャネルに自動的に振り分けられるようになり、承認プロセスがバルク処理の影響を受けにくくなっています。データ移行の作業中に承認フローが止まって困った経験がある人には、地味ですが刺さる改善だと思います。

その他

呼び出し方に関わらずユーザー権限を強制できる設定

フローの実行時プロパティに、「ユーザーコンテキスト – ユーザー権限の適用」という設定が追加されました。これを選択すると、フローがどう呼び出されたかに関わらず、実行中のユーザーのオブジェクト権限・項目レベルセキュリティ・共有ルールが常に強制されます。承認プロセスやAgentforceのアクションから呼び出されるフローなど、呼び出し元が読みにくい構成が増えている今、権限を明示的に縛れる選択肢があるのは安心材料になります。

ここは注意!つまずきポイント

項目値による分岐要素は、1ブランチにつき値を1つしか指定できません。複数の値を同じ経路にまとめたい場合は、これまで通りDecision要素を使ったほうが早いです。

今回紹介した機能の多くはWinter '27のリリースに伴って段階的に有効化されるものなので、組織によっては表示されるタイミングにズレがあります。手元のSandboxで見当たらない場合は、少し時間を置いてから確認してみてください。

まとめ

Winter '27のフロー関連機能を、4つの観点でまとめました。

  • レコードトリガーフロー:項目値による分岐・日付で分岐で分岐の選択肢が増え、保存時のミス検知とロック自動リトライで安定性も上がった
  • スケジュールフロー:ロック自動リトライで、大量データ処理まわりの運用負荷が下がる
  • 画面フロー:リストビュー・関連リストからの一括処理、モーダルサイズ指定、リアクティブな条件付き表示など、待望の機能がまとめて実装された
  • フロー承認プロセス:承認を要求の複数プロセス対応、イベント専用チャネル化で、企業規模での運用に強くなった

共通しているのは、実行して初めて気づいていた問題を、保存時やアーキテクチャレベルで先回りして防ぐ方向性です。派手さはありませんが、本番運用で苦労してきた人ほど価値がわかる変更だと思います。Sandboxのプレビュー期間中に、自組織で影響が大きそうな機能から触ってみてください。一緒に少しずつ慣れていきましょう。

出典:Test Flows in a Dedicated Test Mode (Beta) - Salesforceヘルプ

出典:Salesforce Winter '27 Automation Release Notes

出典:Process Multiple Records With Screen Flows from List Views and Related Lists - Salesforceヘルプ

出典:Salesforce Winter '27 Release Notes


noteもやっています。

note


1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?