プログラム設計のベストプラクティス
プロセスビルダーでプロセスを設計する前に、そのベストプラクティスを理解しておく必要があります。
必要なエディション
| 使用可能なインターフェース: Salesforce Classic (使用できない組織もあります) および Lightning Experience の両方 |
| 使用可能なエディション: Essentials Edition、Professional Edition、Enterprise Edition、Performance Edition、Unlimited Edition、および Developer Edition |
2025 年 12 月 31 日以降も既存のプロセスは引き続き実行され、有効化、無効化、編集ができますが、Flow Builder を使用することをお勧めします。既存のプロセスを移行するには、Flow Builder への切り替えを計画し、 Migrate to Flow ツールを使用します。新しい自動化の場合は、Flow Builder でフローを作成します。
テスト環境を構築する。
プロセスが正しく機能しているかどうかをテストするには、プロセスを有効化する必要があります。本番データに影響を与えずに問題を特定できるように、Sandbox 環境でプロセスを作成してテストします。
オブジェクトごとに 1 つの自動化ツールを使用する。
オブジェクトに 1 つのプロセス、1 つの Apex トリガー、3 つのワークフロールールがある場合、レコード変更の結果を確実には予測できません。
オブジェクトあたり 1 つのレコード変更プロセスのみにする。
レコードが作成または更新されるたびに、そのオブジェクトのすべてのレコード変更プロセスが評価されます。組織でオブジェクトあたり 1 つのレコード変更プロセスに制限することをお勧めします。その理由は次のとおりです。
- オブジェクトに対して組織の自動化の統合ビューを取得するため
オブジェクトの 1 つの統合されたレコード変更プロセスにより、そのオブジェクトのレコードが更新されるたびに評価されるすべての条件や、条件を満たしたときに実行されるアクションを表示できます。
- 制限への到達を回避するため
1 つのオブジェクトのプロセスを 1 つのメインプロセスに統合する場合、それらのプロセスのアクションも統合します。アクションが少ないほど、組織の制限 (SOQL クエリの数など) に達する可能性が低くなります。
- 操作の順序を確定するため
オブジェクトのレコード変更プロセスを複数作成すると、Salesforce では、プロセス評価の順序が保証できなくなります。1 つのプロセスですべてを自動化すれば、順序が明示的に設定されます。最初の条件ノードは最初に評価され、2 番目の条件ノードは 2 番目に評価されるというように順序が明確になります。
1 つのメインプロセスへの道を平坦にする機能をいくつか紹介します。
- ISNEW() — 一部の自動化は、作成されたレコードにのみ適用されます。残りの自動化は、作成されたレコードおよび編集されたレコードに適用されます。そのすべてを 1 つのプロセスに組み合わせることなど、どうしたらできるのでしょうか?そこで、評価するレコードが作成されたばかりであるかどうかを判断する数式関数
ISNEW()のご紹介です。作成専用の自動化をプロセスに追加して、レコードが作成または編集されたときに開始するには、関連条件を数式に変換します。次に、&& ISNEW() を数式に追加してください。
- 呼び出し可能なプロセス — プロセスでフローをコールできるのと同じように、プロセスでその他のプロセスをコールできます。呼び出し可能なプロセスはモジュール形式のプロセスであり、別のプロセスから開始するように指示されたときに限って開始されます。
たとえば、「取引先」プロセスのいくつかの条件ノードがそれぞれある条件 (取引先が重要であるかどうかなど) を評価するとします。重要であるかどうかなどの共通する条件を使用せずに、それらの条件ノードを「主要取引先」呼び出し可能プロセスに移動します。次に、取引先が重要である場合に「主要取引先」プロセスを呼び出すように「取引先」プロセスを設定します。
可能な場合はアクションを統合する。
プロセスで実行するアクションが増えるほど、組織の制限 (DML ステートメントの数や合計 CPU 使用量など) に達する可能性が高くなります。1 つのアクションで間に合う場合は複数のアクションを作成しないようにします。
たとえば、プロセスで取引先の住所を更新するとします。異なるアクションを作成して個々の項目を更新するのではなく、1 つのアクションを作成してすべての住所項目を更新します。
再利用可能なプロセスを作成する。
一部のプロセスアクション (メールアラート、クイックアクション、プロセス、フロー、Apex) は常に再利用できます。ただし、複数の条件グループや複数のプロセスの他のアクション種別はどのように再利用するのでしょうか?
- [レコードを作成] アクションまたは [レコードを更新] アクションを再利用するには、クイックアクションを作成します。クイックアクションは、プロセス、フロー、レコードページで使用できます。
- 他のプロセスアクションを再利用するには、呼び出し可能なプロセスでアクションを設定します。関連する条件グループで、プロセスアクションを追加して呼び出し可能なプロセスをコールします。呼び出し可能なプロセスは、プロセスでのみ使用できます。
以前の変更を上書きするアクションに注意する。
複数のアクショングループが同じ項目を更新するときは、このようにならないようにするか、注意して行ってしてください。
無限ループが発生しないようにする。
たとえば、Process1 の [レコードを更新] アクションが Process2 をトリガーし、Process2 の [レコードを作成] アクションが Process1 をトリガーするとします。 この場合、ループにより組織の上限を超える可能性があります。
ルール適用時のアクションでスケジュール済みアクションがキャンセルされないようにする。
関連付けられた条件が true でなくなると、待機中のスケジュール済みアクションがキャンセルされます。プロセスの後続のルール適用時のアクションで待機中のスケジュール済みアクションが誤ってキャンセルされないようにしてください。
プロセスの順列を可能な限り多くテストする。
Salesforce のすべてのカスタマイズと同じように、作業内容をテストすることが重要です。考え付くかぎり多くの可能性をテストしてから、プロセスを本番組織にリリースしてください。
Salesforce データの変更後に外部データにアクセスするには、スケジュール済みアクションを使用します。
Salesforce が組織のデータを作成、更新、または削除した後、同じトランザクション内で外部データにアクセスした場合、エラーが発生します。プロセスでは、個別のトランザクションを使用して外部システムのデータにアクセスすることをお勧めします。これを行うには、スケジュール済みアクションを追加して前のトランザクションを終了します。レコード変更プロセスの場合、項目ベースのスケジュールは使用しないでください。
たとえば、カスタムプラットフォームイベント「Order Status (注文状況)」からプラットフォームイベントメッセージを受信したときイベントプロセスが開始されるとします。注文状況が [新規] の場合、プロセスによって取引先責任者が作成され、外部システムの注文状況を更新するアクションがスケジュールされます。スケジュール済みアクションで外部システムにアクセスするための個別のトランザクションが作成されるため、イベントプロセスは失敗しません。
