Salesforceフローの作り方。レコードトリガーで更新と通知を自動化する

Salesforceで「これを自動にしたい」と思ったときに使う道具は、いまはフローの1つだけです。この記事では、商談が受注になった瞬間に導入プロジェクトを1件作り、担当営業とマネージャーにメールと通知を飛ばすフローを、開始条件の決め方から有効化まで作ります。後半では、完了予定日を過ぎた導入プロジェクトを毎朝知らせるスケジュールトリガーフローも作ります。読み終わると、受注後の引き継ぎ漏れがなくなり、別の自動化も同じ考え方で組めます。前提は、システム管理者のプロファイルでログインしていること（「フローの管理」と「すべてのデータの参照」の権限が要ります）と、エディションが Essentials 以上であること（Starter は対象外）です。Classicの画面の説明は読み飛ばしてかまいません。ここでは Lightning Experience だけを扱います。

この記事の内容

1. 先に決めること
2. 設計表
3. 作る手順
4. 応用：完了予定日を過ぎた導入プロジェクトを毎朝知らせる
5. 上限とガバナ制限で当たるところ
6. できないことと、その代わり
7. よく詰まるところ
8. 次にやること

先に決めること

フローは線をつなぐだけで作り始められるので、決めずに作ると、導入プロジェクトが2件できる、通知が何十通も飛ぶ、Professional で本数の上限に当たる、という形で作り直しになります。作る前に次の5つを決めます。

どの種類のフローで作るか

フローは「いつ動き出すか」で種類が分かれます。最初に動き出すきっかけに合う種類を選びます。営業管理で使うのは、ほぼ次の5つです。

種類	動き出すきっかけ	営業チームでの使いどころ
画面フロー	人がボタンを押す・ページで開く	入力画面を案内する（受注時の確認項目を順に聞く等）
レコードトリガーフロー	レコードの作成・更新・削除	受注したら導入プロジェクトを作る、フェーズが変わったら通知する
スケジュールトリガーフロー	決めた時刻（1回・毎日・毎週）	毎朝、期限切れの導入プロジェクトを知らせる
自動起動フロー（トリガーなし）	ほかのフロー・Apex・ボタンからの呼び出し	複数のフローで使う共通処理を部品にする
プラットフォームイベントトリガーフロー	プラットフォームイベントの発生	外部システムからの合図で処理を動かす

レコードトリガーフローはさらに、保存の前に動くもの、保存の後に動くもの、削除の前に動くものに分かれます。保存前は同じレコードの項目を書き換えるだけの軽い処理、保存後は別のレコードを作る・メールを送るといった処理です。この記事の例は、別のオブジェクト（導入プロジェクト）にレコードを作るので保存後になります。

ワークフロールールとプロセスビルダーはもう使わない

古い解説記事にはワークフロールールやプロセスビルダーで作る手順が出てきますが、どちらも公式のサポートと更新が2025年12月31日で終わりました。既存のものは引き続き動き、有効化・無効化・編集もできますが、不具合は直りません。公式ヘルプも、新しい自動化は Flow Builder で作ること、既存のものは「フローに移行」ツールで移すことを勧めています。

「設定」の「クイック検索」に「フローに移行」と入れて開き、移すプロセスかワークフロールールを選んで「フローに移行」を押します。できたフローを Sandbox でテストして有効化し、元のプロセスやルールを無効化します。両方を有効のまま残すと同じ処理が2回走ります。なお、ワークフロールールはもともと Enterprise 以上の機能で、Professional の組織には存在しません。

1つのオブジェクトにフローをいくつ作るか

Essentials と Professional には本数の上限があります。公式の一般的なフローの制限では「フロー種別ごとの有効なフロー」が5、「フロー種別あたりの合計フロー数」も5です。数えるのはオブジェクトごとではなく組織全体で、同じ種別のフローは組織全体で有効5本までです。Enterprise 以上はそれぞれ2,000と4,000です。Professional で商談の保存後のレコードトリガーフローを「受注時」「失注時」「金額変更時」とばらばらに作ると、それだけで3本使います。

なので、実際に回っている形では「1つのオブジェクトの保存後の処理は1本のフローにまとめ、中で決定要素を使って分岐する」にしています。商談なら「商談_保存後」の1本です。ただし、オブジェクトごとに1本にまとめても、保存後のレコードトリガーフローを置くオブジェクトが5つを超えると足りなくなります。保存前と保存後は別の種別として数えるので、同じ商談でも保存前の処理は別枠です。Professional では、どのオブジェクトに自動化を置くかを先に5つ以内に絞ります。Enterprise でも本数が少ないほうが、どのフローが何をしているかを追いやすくなります。

二重に動かさない仕組みを先に入れる

受注で導入プロジェクトを作るフローで一番多い事故は、同じ商談に2件できることです。原因は2つあります。1つは開始条件の設定で、受注済みの商談の金額を直すたびにフローが動く設定にしてしまうことです。もう1つは、営業が一度「商談成立」にした商談を戻して、また「商談成立」にすることです。

1つ目は開始条件の「更新されたレコードでフローを実行するタイミング」で防ぎます（手順で詳しく書きます）。2つ目は開始条件では防げないので、フローの中で「この商談の導入プロジェクトがすでにあるか」を「レコードを取得」で調べ、あれば何もしないで終わる形にします。

誰に何で知らせるか

知らせ方は「メールを送信」アクションと「カスタム通知を送信」アクションの2つを使い分けます。

比べる点	メールを送信	カスタム通知を送信
届く場所	受信者のメールボックス	Salesforce 画面右上のベル・モバイルアプリ
社外に送れるか	送れる	送れない（ユーザーだけ）
押すとレコードに飛ぶか	本文にリンクを書けば飛ぶ	対象のレコードを指定すれば飛ぶ
準備	送信の設定とメールの検証	通知ビルダーで通知種別を1つ作る
使えるエディション	Flow Builder と同じ	Essentials・Professional・Enterprise ほか

社内の営業とマネージャーに知らせるなら、両方送ります。営業はメールで、社内のマネージャーはベルで気づきます。毎朝の遅延通知のように件数が増えるものは、受信箱が埋まって読まれなくなるのでカスタム通知だけにします。

公式の Flow Builder の対応エディションは Essentials・Pro Suite・Professional・Enterprise・Performance・Unlimited・Developer です。Starter はこの一覧にないので、この記事の内容は Essentials 以上が前提です。

設計表

作るものは3本です。例の組織（営業5名・マネージャー1名、カスタムオブジェクト「導入プロジェクト」あり）で作る値をそのまま載せます。

フローの表示ラベル	種類	オブジェクト	動き出す条件	中でやること
商談_保存後	レコードトリガーフロー（アクションと関連レコード）	商談	フェーズが「商談成立」になったとき	導入プロジェクトがなければ作る・メール・カスタム通知
導入プロジェクト_遅延通知	スケジュールトリガーフロー	導入プロジェクト	毎日8:00、状況が「完了」以外	遅れ日数が1以上ならカスタム通知
（応用）導入プロジェクト_期限前	レコードトリガーフロー＋スケジュール済みパス	導入プロジェクト	作成時	完了予定日の3日前に通知

受注時に作る導入プロジェクトには、次の値を入れます。

導入プロジェクトの項目	入れる値	補足
導入プロジェクト名	商談名＋「（導入）」	数式リソースで組み立てる
取引先（主従関係）	商談の取引先	主従関係なので必須。商談に取引先がないと失敗する
元の商談（参照関係）	商談の ID	二重作成の判定にも使う
状況	未着手	選択リストの既定値と同じでも明示して入れる
開始日	フローが動いた日	$Flow.CurrentDate
完了予定日	動いた日の60日後	数式リソース {!$Flow.CurrentDate} + 60
進捗率	0	空のままだと遅れ日数の数式が崩れることがある

導入プロジェクトは取引先との主従関係の子なので、所有者の項目がありません。通知の宛先は「元の商談」の所有者（担当営業）と、その上司（マネージャー）にします。ユーザーの上司の欄（API参照名 ManagerId）が空の営業がいると、宛先が欠けます。フローを作る前に、営業5名全員のユーザー情報で上司を設定しておきます。

作る手順

準備：組織の設定を2つ確かめる

1. 「設定」の「クイック検索」に「プロセスの自動化設定」と入れて開きます。
2. 「デフォルトのワークフローユーザー」に、退職しない管理者ユーザーを入れます。スケジュールトリガーフローはこのユーザーとして動き、スケジュール済みパスでも使われます。
3. 同じページの下のほうにある「プロセスまたはフローのエラーメールの送信先」を確かめます。既定の「プロセスまたはフローを最後に変更したユーザー。」だと、最後に触った人にエラーメールが届きます。受け取る担当が決まっていれば「Apex 例外メールの受信者」に切り替えます。
4. 「保存」を押します。

例1：商談成立で導入プロジェクトを作る

最初にフローを新規作成し、開始条件を決めます。

1. 「設定」の「クイック検索」に「フロー」と入れ、「フロー」を開きます。
2. 「新規フロー」を押します。
3. カテゴリの「トリガーオートメーション」を選びます。
4. 「レコードトリガーフロー」を選びます。Flow Builder が開き、開始要素の設定が表示されます。
5. 「オブジェクト」で「商談」を選びます。
6. 「トリガーを設定」の「フローをトリガーする条件:」で「レコードが作成または更新された」を選びます。
7. 「エントリ条件を設定」の「条件の要件」で「すべての条件に一致 (AND)」を選びます。
8. 条件に「フェーズ」「次の値と一致する」「商談成立」を入れます。標準のフェーズ値で、英語の値は「Closed Won」です。
9. 「更新されたレコードでフローを実行するタイミング」で「条件の要件に一致するようにレコードを更新したときのみ」を選びます。
10. 「フローを最適化」で「アクションと関連レコード」を選びます。

手順9が、二重作成の1つ目の防ぎ方です。公式ヘルプの説明を自分の言葉に直すと、2つの選択肢の違いは次のとおりです。

選択肢	動く場面	受注済みの商談の金額を直したとき
レコードを更新し、条件の要件に一致するたび	更新後に条件を満たしていれば毎回	動く（導入プロジェクトがもう1件できる）
条件の要件に一致するようにレコードを更新したときのみ	条件を満たしていない状態から満たす状態に変わったときだけ	動かない

新規作成のレコードは「更新前は条件を満たしていなかった」と扱われるので、最初から「商談成立」で作った商談でも動きます。データインポートで過去の受注商談をまとめて入れると、その件数だけ導入プロジェクトができます。移行作業の前には、このフローを無効化しておきます。

手順10の「高速項目更新」は保存前の処理で、使える要素が割り当て・決定・レコードを取得・ループだけなので、今回は必ず「アクションと関連レコード」です。

次に、すでに導入プロジェクトがあるかを調べます。

1. 開始要素の下の「+」を押し、「レコードを取得」を選びます。
2. 表示ラベルに「既存の導入プロジェクトを取得」と入れます。
3. オブジェクトに「導入プロジェクト」を選びます。
4. 条件に「元の商談」「次の値と一致する」、値に開始要素の商談の ID（{!$Record.Id}）を入れます。
5. 「保存するレコード数」で「最初のレコードのみ」を選びます。
6. 「+」を押し、「決定」を選びます。
7. 結果を1つ作り、表示ラベルを「まだない」、条件を「既存の導入プロジェクトを取得」「null である」「True」にします。既定の結果（それ以外）は何もしないで終わる側です。

導入プロジェクトを作ります。導入プロジェクト名と完了予定日は、先に数式リソースを作っておきます。

1. ツールボックスを開き、「新規リソース」を押します。
2. リソース種別に「数式」を選び、API 参照名を ProjectName、データ型を「テキスト」、数式を {!$Record.Name} & "（導入）" にします。
3. もう一度「新規リソース」から「数式」を選び、API 参照名を PlannedEndDate、データ型を「日付」、数式を {!$Flow.CurrentDate} + 60 にします。
4. 決定の「まだない」側の「+」を押し、「レコードを作成」を選びます。
5. 表示ラベルに「導入プロジェクトを作成」と入れます。
6. 「作成するレコード数」は1件、「レコード項目の設定方法」は「手動」を選びます。
7. オブジェクトに「導入プロジェクト」を選びます。
8. 「項目を追加」で、設計表の7項目を1つずつ足して値を入れます。取引先は {!$Record.AccountId}、元の商談は {!$Record.Id} です。

最後に保存します。

1. 右上の「保存」を押します。
2. 「フローの表示ラベル」に「商談_保存後」と入れます。「フローの API 参照名」は自動で入ります。
3. 説明に「商談成立で導入プロジェクト作成・通知」と書きます。半年後に見た人がこれだけで用途を分かるようにします。
4. 「保存」を押します。

例2：営業とマネージャーにメールとカスタム通知を送る

例1と同じフローの続きに足します。まず「カスタム通知を送信」で使う通知種別を作ります。これはフローの外の設定です。

1. 「設定」の「クイック検索」に「通知ビルダー」と入れ、「カスタム通知」を開きます。
2. 「新規」を押すと「新規カスタム通知種別」の画面が開きます。
3. 「カスタム通知名」に「受注通知」と入れます。「API 参照名」は Juchu_Tsuchi にします。
4. 「サポートされるチャネル」で「デスクトップ」と「モバイル」にチェックを入れます。
5. 保存します。モバイルを選んだ場合は「通知の配信設定」で Salesforce モバイルアプリを有効にします。

次にメールです。件名と本文はテキストテンプレートにしておくと、あとで文面を直しやすくなります。

1. フローに戻り、「新規リソース」から「テキストテンプレート」を作ります。API 参照名は MailBody です。
2. 本文に「{!$Record.Name} が受注になりました。金額：{!$Record.Amount}　担当：{!$Record.Owner.LastName}。導入プロジェクトを作成しました。」と書きます。
3. 「導入プロジェクトを作成」の下の「+」を押し、「アクション」を選びます。
4. 「メールを送信」を検索して選びます。
5. 表示ラベルに「受注メール」と入れます。
6. 宛先は「受信者アドレスリスト」（カンマ区切りのテキスト）か「受信者アドレスコレクション」（テキストのコレクション変数）のどちらかに入れます。ここでは数式リソース MailTo を作り、{!$Record.Owner.Email} & IF(ISBLANK({!$Record.Owner.Manager.Email}), "", "," & {!$Record.Owner.Manager.Email}) として「受信者アドレスリスト」に渡します。上司が空の営業でも、本人にだけは届きます。
7. 件名に「【受注】{!$Record.Name}」、「本文」に MailBody を指定します。

カスタム通知は、宛先をテキストのコレクション変数に入れてから送ります。

1. 「新規リソース」から「変数」を作り、API 参照名を RecipientIds、データ型を「テキスト」にして「複数の値を許可 (コレクション)」にチェックを入れます。
2. 「+」から「割り当て」を選び、RecipientIds に「追加」で {!$Record.OwnerId} を入れます。行を足して、上司の ID（{!$Record.Owner.ManagerId}）も「追加」します。
3. 「+」から「レコードを取得」を選び、表示ラベルを「通知種別を取得」、オブジェクトを「カスタム通知種別」、条件を「名前」「次の値と一致する」「Juchu_Tsuchi」にします。公式ヘルプでは「名前」の項目が2つあり、API 参照名が DeveloperName のほうを使うとされています。
4. 「+」から「アクション」を選び、「通知」で検索して「カスタム通知を送信」を選びます。
5. 「カスタム通知種別 ID」に手順3で取ったレコードの ID、「受信者 ID」に RecipientIds、「通知タイトル」に数式リソース NotifTitle（"受注：" & {!$Record.Name}）、「通知本文」に MailBody を入れます。
6. 「対象 ID」のスイッチを「含む」にして、作成した導入プロジェクトの ID を入れます。通知を押すと導入プロジェクトの画面が開きます。
7. 「保存」を押します。

メールアラートがすでにある組織なら、「アクション」でその名前を検索して置き、「レコード ID」に {!$Record.Id} を渡すだけでも送れます。新しく作るなら、文面をフローの中で直せる「メールを送信」が楽です。

テストする

テストは2段階で見ます。Flow Builder の中で流れと値を確かめ、そのあと有効化して Sandbox で商談を実際に更新して結果を見ます。Flow Builder の上部には「デバッグ」と「テストを表示」が並んでいます。ここでは「デバッグ」で1回流して確かめます。

1. Flow Builder の上部の「デバッグ」を押します。左に「デバッグ」のパネルが開きます。
2. 「パスを選択」の「デバッグ実行のパス」は「即時実行」のままにします。
3. 「トリガーレコードを設定」の「レコードが次の場合にフローを実行:」で「更新済み」を選び、その下の検索欄でテスト用の商談を選びます。
4. 「デバッグオプションを選択」で「開始条件の要件をスキップ」にチェックを入れ、「実行」を押します。
5. パネルの「詳細」に、各要素の通った順番と結果が並びます。「すべて展開」を押して、決定がどちらに進んだか、作成する項目の値が設計表どおりかを見ます。

レコードトリガーフローのデバッグは常にロールバックモードで動きます。デバッグ中に作られた導入プロジェクトは残らず、「メールを送信」も実際には送られません。メールの文面や、本当に1件だけできるかは、次の有効化の手順で Sandbox の商談を実際に更新して確かめます。「テストを表示」からはテストを保存しておけるので、直すたびに同じ条件で流し直せます。

有効化とバージョン

Sandbox で作り、Sandbox で有効化して確かめてから本番に移すのが基本です。Sandbox がない場合は、本番に「テスト用」と分かる取引先と商談を作り、宛先を自分にしてから試します。

1. 右上の「有効化」を押します。
2. Sandbox の一覧に戻り、テスト用の商談のフェーズを「商談成立」にして保存します。
3. 導入プロジェクトが1件でき、メールとベルの通知が届くことを確かめます。メールの文面もここで読みます。
4. 同じ商談の金額を直して保存し、導入プロジェクトが増えないことを確かめます。

有効化したフローを直すときは、上部の「新規バージョンとして保存」で保存します。新しいバージョンを有効化すると、それまで有効だったバージョンは自動で無効になります。ただし、すでに動き出していた処理は、動き出したときのバージョンのまま最後まで走ります。1つのフローに持てるバージョンは50までなので、古いバージョンはときどき削除します。

応用：完了予定日を過ぎた導入プロジェクトを毎朝知らせる

スケジュールトリガーフローで作る

1. 「設定」の「フロー」で「新規フロー」を押し、「スケジュールトリガーフロー」を選びます。
2. 開始要素の「スケジュールを設定」で「開始日」を今日、「開始時刻」を8:00、「頻度」を「毎日」にします。時刻は組織の既定のタイムゾーンで解釈されます。
3. 「オブジェクトおよび検索条件を選択」で「オブジェクト」に「導入プロジェクト」を選び、条件を「状況」「次の文字列と一致しない」「完了」にします。ここで絞るほど、動く件数が減ります。
4. 「+」から「決定」を置き、結果「遅れている」の条件を「遅れ日数」「次より大きい」「0」にします。
5. 「遅れている」側で、元の商談の所有者を RecipientIds に入れる割り当てを置きます。
6. 例2と同じ手順で「カスタム通知を送信」を置きます。タイトルは「遅延：」のあとに {!$Record.Name} と遅れ日数を差し込みます。遅れ日数は「リソースを挿入」から項目を選ぶと、その項目の API 参照名で入ります。
7. 保存して、「有効化」を押します。

スケジュールトリガーフローは、条件に合ったレコード1件ごとに1回動きます。遅れている案件が20件あれば通知も20件です。多すぎるなら宛先は担当営業だけにし、マネージャーはダッシュボードで遅れ日数の一覧を見る形にしたほうが回ります。

動いたかどうかは「設定」の「スケジュール済みジョブ」で見られます。ここでジョブを削除すると今後の実行もすべて止まり、再開するにはフローを無効化してから有効化し直します。スケジュールトリガーフローから「メールを送信」を使う場合は、「設定」で組織のメールアドレスを登録し、「プロセスの自動化設定」の「自動化プロセスユーザーのメールアドレス」にも入れておく必要があります。

期限の3日前に知らせる（スケジュール済みパス）

毎朝まとめて見るより、1件ずつ前もって知らせたい場合は、導入プロジェクトのレコードトリガーフローにスケジュール済みパスを足します。

1. 導入プロジェクトで、作成時に動くレコードトリガーフローを作り、「フローを最適化」を「アクションと関連レコード」にします。スケジュール済みパスはこの設定でしか使えません。
2. 開始要素で「スケジュール済みパスを追加 (省略可能)」を押します。
3. パスの表示ラベルに「期限3日前」と入れます。
4. 「時間取得元」に「完了予定日」を選びます。
5. 「オフセット数」に3、「オフセットオプション」に「日前」を選びます。
6. そのパスの下に「カスタム通知を送信」を置きます。

待機中のパスは「設定」の「時間ベースのオートメーション」で見られます。条件を満たさなくなる更新をすると、予定済みのパスは取り消されます。

上限とガバナ制限で当たるところ

フローは Apex と同じトランザクション単位の制限を受けます。初めて作る人が当たるのは次の数字です。

制限	値	フローで数えられるもの
発行される SOQL クエリの総数	100	レコードを取得、条件付きのレコードを更新・削除
発行される DML ステートメントの合計数	150	レコードを作成・更新・削除
SOQL で取得されるレコードの総数	50,000	取得した件数の合計
DML で処理されるレコードの合計数	10,000	作成・更新・削除した件数の合計
CPU 時間	10,000ミリ秒	同じトランザクションの Apex トリガーなどと合算
スケジュールトリガーフローの24時間あたりの実行数	250,000か、ユーザーライセンス数×200の大きいほう	条件に合ったレコード1件につき1回

一番多い原因は、ループの中に「レコードを作成」や「レコードを更新」を置くことです。公式ヘルプにも、ループ内の「レコードを作成」は繰り返しごとに1回の DML になり自動ではまとめられないとあります。ループの中では「割り当て」でコレクション変数に溜め、ループを抜けたあとで「レコードを作成」を1回だけ置きます。同じ理由で、ループの中に「レコードを取得」も置きません。

一方、データローダーで商談を100件まとめて更新したような場合は、Salesforce が100件分のフローの同じ要素をまとめて1回の操作にしてくれます。1件ずつ動くフローを書いても上限には当たりにくくなります。ただし、まとめた結果でも制限を超えるとトランザクション全体が取り消され、障害パスを用意していても取り消されます。

できないことと、その代わり

やりたいこと	標準のフローでは	代わりの手
社外の人に Slack や LINE で知らせる	標準のアクションにはない	AppExchange の連携アプリか、Apex での呼び出し
保存前の処理で別のレコードを作る	できない（高速項目更新は同じレコードの更新だけ）	アクションと関連レコードに切り替える
数式項目の参照先が変わったときに動かす	参照先の変更ではフローは動かない	参照先のオブジェクト側にフローを置く
Professional で6本目の同じ種類のフローを有効にする	同じ種別は組織全体で有効5本まで	自動化を置くオブジェクトを絞り、1オブジェクト1本にまとめて決定で分岐する。足りなければ Enterprise へ
スケジュールトリガーフロー・画面フローを実データに触れずにデバッグする	ロールバックモードにしないと実データが変わる	Sandbox でデバッグする
過去にさかのぼって一括で動かす	レコードトリガーフローは保存されたときだけ動く	一度だけ動くスケジュールトリガーフローを作るか、データローダーで更新し直す
ワークフロールールとフローの両方で同じ処理	二重に動く	「フローに移行」のあと元を無効化する

よく詰まるところ

症状	原因	直し方
導入プロジェクトが同じ商談に2件できる	実行タイミングが「一致するたび」になっている、または商談成立を戻して付け直した	「条件の要件に一致するようにレコードを更新したときのみ」にし、レコードを取得と決定で既存を確かめる
有効化したのに動かない	開始条件の値が実際の選択リスト値と違う（ラベルと値の取り違え）	条件の値を選択肢から選び直し、デバッグで開始条件をスキップせずに試す
「REQUIRED_FIELD_MISSING」のエラーメールが届く	商談に取引先がなく、主従関係の取引先が空になった	商談の取引先を必須にするか、決定で取引先が空なら作らない分岐を足す
「有効化」を押せない	トリガー付きのフローには「すべてのデータの参照」権限が要る	権限セットで付けるか、システム管理者で有効化する
Professional で新しいフローを有効化できない	同じ種別の有効なフローが組織全体で5本に達した	同じオブジェクトのフローを1本にまとめ、自動化を置くオブジェクトを絞る
メールが届かない	「メールを送信するためのアクセス権 (すべてのメールサービス)」が「すべてのメール」でない、または送信者のメール検証が済んでいない	「設定」の「送信」でアクセス権を「すべてのメール」にし、送信者アドレスを検証する
「受信者が 0 人」のエラーになる	上司が未設定で、宛先の変数が空になった	全ユーザーの上司を埋めるか、決定で空のときは宛先に足さない
カスタム通知が届かない	通知種別のモバイル配信が未設定、または Winter ’21 以降の組織で実行ユーザーに「カスタム通知の送信」権限がない	通知の配信設定でアプリを有効にし、権限を確かめる
スケジュールトリガーフローをデバッグしたら本物のレコードが変わった	スケジュールトリガーフローや画面フローのデバッグは、ロールバックモードにしないと実際に実行される	Sandbox で試すか、ロールバックモードを選ぶ。変わったレコードは手で戻す
項目を消したらフローが「UNKNOWN_EXCEPTION」で止まる	フローが参照していたカスタム項目を削除した	項目を消す前に全バージョンの参照を外す
スケジュールトリガーフローが動かない	一度だけの設定で開始日時を過ぎていた、またはスケジュール済みジョブを削除した	開始日時を見直し、無効化してから有効化し直す
エラーメールがほかの人に届く	既定ではフローを最後に変更した管理者に届く	「プロセスまたはフローのエラーメールの送信先」を変える

エラーメールには、どの要素で何が足りなかったかと、Flow Builder でその実行を開き直すリンクが入っています。要素の表示ラベルが「レコードを取得1」のままだと、どこで止まったか分かりません。中身の分かる名前を付けておくのが一番効きます。

次にやること

受注時の自動化ができたら、受注の前の段階を固めます。値引き率が大きい商談を上長に通してから受注にするなら「Salesforceの承認プロセスの作り方。値引き申請を上長承認にする」に進みます。導入プロジェクトの項目や遅れ日数の数式をまだ作っていなければ「Salesforceのカスタムオブジェクトと項目の作り方。選択リスト・数式・主従関係」が先です。フローで入れた値を人が書き換えないようにするには「Salesforceの入力規則とアクセス権。入力漏れと見せたくないデータを防ぐ」、遅れている導入プロジェクトを会議で一覧にするには「Salesforceのダッシュボードの作り方。営業会議で見る1枚を作る」を読んでください。