ProcessBuilderのベストプラクティス
こんにちは私は頂点のコーディングを学ぶために本を読んでいて、PBに関連するこの段落を見つけました：
ベストプラクティスは、単一のオブジェクトに対して、この1つのプロセスを通じて管理されるすべてのコントロールで定義された単一のProcessBuilderプロセスがあることを確認することです。実際には、これは常に保守可能であるとは限らず、プロセスをApexトリガーに移行する必要がある場合があります。オブジェクトごとに複数のプロセスが必要な状況に陥った場合は、これらのプロセスをApexに移行することを検討する必要があります。
バティソン、ポール。Apexを使用したSalesforce開発の学習：Apexコードを簡単に記述、実行、およびデプロイする（英語版）（p.26）。BPB出版物。キンドル版。
これから私が理解しているのは、Process Builderでオブジェクトに対して行われたすべての更新は、1つのプロセスで実行する必要があるということです。
各オブジェクトに10以上のプロセスがあることを考えると、私は少し心配しています...
回答
オブジェクトに対して単一のプロセスビルダーを使用することは正しいアプローチですが、このルールの例外は、作成イベント用に1つ、更新イベント用に1つのプロセスビルダーがある場合です。
オブジェクトのPBの制限についてsalesforce.stackexchange.comでこの質問を確認してください
プロセスビルダーのベストプラクティスについては、次のリンクを参照してください。
PBの10のベストプラクティス
Salesforce ProcessBuilderのベストプラクティス
この質問で尋ねるつもりだった他の質問がある場合は、質問を更新してください。
乾杯
はい、フローの統合はベストプラクティスと見なされます。Process Builderフローの統合を迫られた組織で働いたことがあるので、良い面と悪い面の両方について話すことができます。この方向にプッシュされた理由は、いくつかのオブジェクトの保存操作でガバナーの制限に達していたためです。これらのフローを統合すると、フローが問題に寄与する範囲でこの問題が修正されます。非常に複雑な組織があり、ガバナー制限の例外を遵守している場合は、フローの統合をそれらに対処するための初期ステップとして確実に検討する必要があります。
欠点については、いくつかあります。一つには、バージョン管理が少し混乱します。また、基本的に「Process Builderで問題が発生した」ことしかわからず、どのノードが問題を引き起こしたかがまったくわからないため、フローのエラー処理がすでに不十分であることが悪化します。ライブの問題は詳細を提供するエラーメールを送信しますが、単体テストで問題が発生すると、非常に乾燥した状態になります。テストを実行し、正しいログファイルとそのセクションを追跡できることを期待する以外に、文字通り調査する方法はありません。デプロイメントの検証中にのみ発生するエラーがある場合、特にこの戦略を検討する必要がある組織は検証に長い時間がかかる傾向があるため、これは非常に難しい場合があります。
統合する場合は、単体テストの目的でフローをバイパスできるフィールドをオブジェクトに追加することを強くお勧めします。そうしないと、システム全体が脆弱になりすぎて管理できなくなります。
私もこの推奨事項を読みましたが、私にとってプロセスの保守性/読みやすさは非常に重要です。アカウントには正確に10個のプロセスがあり、作成イベント用のものと更新イベント用のものがあります。
フィールドをコピーするプロセスもあれば、オブジェクトを作成するプロセスもあり、メールアラートを呼び出すプロセスもあります。もちろん、これらはすべて異なる条件を持っています。将来的にはアクションを生み出すものさえあります。これらを2つのプロセス（1つは作成用、もう1つは更新用）に配置すると、プロセスが非常に大きくなる可能性があります。
保守性の側面について詳しく言うと、オブジェクトごとに1つのプロセスしかなく、サンドボックスで新しい機能に取り組んでいると仮定します。本番環境で簡単な修正を行う必要があるとしましょう。この修正は新機能とは何の関係もありませんが、同じオブジェクトに適用されます。それはすべて1つの大きなプロセスであるため、サンドボックスにも適用する必要があります。そして、それはプロセスの洗練された更新ではありません。チェンジセットは単に新しいバージョンを追加するだけで、何もマージしません。
また、機能の1ビットを一時的に無効にする場合：個別のプロセスがある場合は、適切なプロセスを非アクティブにするだけです。大きなプロセスが1つある場合は、条件をどこかで編集し、どこで何をしたかを覚えておく必要があります。それで頑張ってください。
オブジェクトのすべての機能を1つの大きなプロセスにまとめることは、保守性について学んだすべての教訓に反します。
そのため、今のところ、それらを別々のプロセスに保持しています。Apexクラスへの移行の推奨事項については、それはばかげています。プロセス/フロー/ワークフローを介して要件を満たすことができない場合にのみ、Apexプログラミングを検討する必要があります。Apexコードはエラーが発生しやすく、組織の柔軟性が大幅に低下します。