同じオブジェクトにレコードが保存される前に実行されるように設定されたレコードトリガーフローが複数ある場合、フローの実行順序は予測できません。つまり、どのフローが最初または最後に実行されるか、またはフローが互いのフィールド更新にどのように影響するかを保証できません。したがって、同じオブジェクトに複数の保存前フローを作成することは避け、可能であれば 1 つのフローに統合する必要があります。
参考: https://help.salesforce.com/s/articleView?id=sf.flow_considerations_recordtriggered_before.
html&type=5 より

Bulk API と Dataloader.io はどちらも、Salesforce 内の大量のレコードを更新するために使用できるツールです。
Bulk API は、データのバッチを送信することで、何百万ものレコードを非同期で作成、更新、削除、またはクエリできる RESTful API です。Dataloader.io は、シンプルなユーザー インターフェイスを使用してデータをインポート、エクスポート、または削除できる Web ベースのデータ ローダー ツールです。参考資料:
https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm
https://dataloader.io/

運用環境への展開を成功させるために管理者が従うべき 2 つのプラクティスは次のとおりです。
* 依存コンポーネント リストに加えて、送信変更セットに権限とアクセス設定を追加します。これにより、変更セット内のコンポーネントの権限や設定が不足していることが原因で発生するデプロイメント エラーやアクセスの問題を回避できます。たとえば、変更セットに新しいカスタム オブジェクトが含まれている場合、管理者はそのオブジェクトのオブジェクト権限、フィールド レベルのセキュリティ、ページ レイアウト、レコード タイプも含める必要があります。
* 運用環境にアップロードする前に、サンドボックスで変更セットのデプロイメント検証を実行します。これにより、運用環境にデプロイする前に、変更セットにエラーや競合がないかテストできます。デプロイメント検証では、実際に変更を加えずにデプロイメントをシミュレートし、問題や警告を報告します。
他の 2 つのオプションは、次の理由で正しくありません。
* 変更セットを複製しても、アップロードされた変更セットに忘れられた依存コンポーネントは追加されません。アップロード前に変更できる既存の変更セットのコピーが作成されるだけです。
* 新しいレコード タイプをデプロイする場合、変更セット内の唯一のコンポーネントとしてそれを含める必要はありません。互換性があり、必要な依存関係がある限り、他のコンポーネントと一緒にデプロイできます。
参考資料: https://help.salesforce.com/s/articleView?id=sf.change_sets_components.htm&type=5
https://help.salesforce.com/s/articleView?id=sf.change_sets_deploy.htm&type=5 https://help.salesforce.com/s
/articleView?id=sf.change_sets_validate.htm&type=5