このテキストは、Salesforce の自動翻訳システムを使用して翻訳されました。アンケートに回答して、このコンテンツに関するフィードバックを提供し、次に何を表示するかをお寄せください。

更新スケジュールについては、こちらを参照してください。

システムは、ビジネスが主要な目標と目標をより迅速かつ大規模に達成できるようにすることで、自動化された動作を示します。健全な自動化により、ユーザーは価値の高い作業に集中でき、反復的な手作業や複雑なデータ入力に費やす時間を短縮できます。

多くの場合、自動化とは、ビジネスプロセスを紙ベースのフォームからデジタルフォームへ、古いシステムから新しいシステムへ翻訳することです。ビジネスプロセスの翻訳には、必ず変革の機会が伴います。

変革とは、新しいテクノロジーを使用して、ユーザーの混乱を招くような変化をもたらすことではありません。トランスフォーメーションとは、作業をよりシンプルにする方法を作成し、円滑にビジネスを成長させ、ビジネスユーザーが関係者にとって本当に重要なことにより深く集中できるようにすることです。アーキテクチャの観点からは、完全に排除できる ToDo、または自動的に処理できる ToDo を特定する必要があります。テクノロジーの使用方法とビジネスに対する測定可能な影響を明確に関連付ける必要があります。

Salesforce での自動化に関する重要事項: プログラムによるスキルセットと宣言型のスキルセットを使用して、さまざまなツールで自動化できます。適切に設計された自動化を設計するとは、1 つの自動化ツールのみで構築することを選択することではありません。一貫性のある予測可能なアプローチを使用し、チームが設計した自動化を開発、テスト、リリース、維持できるようにすることです。自動化は、可能な限り保守可能で読みやすい形式にする必要があります。

このセクションでは、企業が主要な目標をより迅速かつ大規模に達成できるように自動化を設計およびリファクタリングする方法について説明します。効率性とデータの整合性に重点を置くことで、Salesforce の自動化のアーキテクチャを改善できます。

自動化の効率を高めるのは、Salesforce テクノロジーを使用して通常どおりビジネスを忠実に再現することではありません。これは、チームがミーティングや追跡の責任を負う主要な評価指標とビジネス上の成果を深く理解し、一歩下がって自動化している作業内および作業全体の機能ユニットを確認することです。自動化を使用してパターンを作成し、ビジネスをより効果的かつ迅速に大規模に運営する方法を特定することです。

効率的な自動化ロジックにより、次のことが可能になります。

  • 拡張性とビジネスにとっての価値の向上
  • ユーザーにとってより役立つ
  • 適応性と進化するビジネスニーズに対応

プロセス設計と運用ロジックを使用して、自動化の効率を向上させることができます。

プロセス設計には、作業方法の定義が含まれます。真に効率的で効果的なプロセスを構築することは、設計が現在の働き方を再現するだけではないことを意味します。効果のないステップや不明確なステップを特定して削除することが重要です。最適化されたプロセスでは、不要な手順を実行せずに測定可能なビジネス価値 (「KPI」を参照) を生み出す必要があります。不明確なステップや不必要なステップがあると、技術的な負債が発生し、自動化のメンテナンスができなくなる可能性があります。

多くの場合、ビジネスプロセスの検出と文書化の責任は、ビジネスアナリストやシステム管理者にも任されます。アーキテクトは、チームのこれらのメンバーと協力して、プロセス設計が技術的に健全で適切に構成されていることを確認する責任があります。Salesforce Platform に関する Knowledge をできるだけ早く適用することで、チームは自動化によって合理化するプロセスや、コストのかかるカスタマイズを回避するために変更が必要なプロセスを特定できます。

Salesforce 用に最適化されたプロセスを構築するには、次の点を考慮してください。

  • プロセスを徹底的に定義します。目的が不明確なプロセスや定義があいまいなプロセスは、設計時に誤って解釈される可能性が高くなります。これにより、前提条件に基づく設計に欠陥が生じ、不正確または非効率的な自動化になります。自動化するビジネスプロセスが次の標準を満たしていることを確認します。

    • 1 つの特定の機能に限定 (「機能単位」を参照)
    • 明確に定義された測定可能な出力がある(「ビジネス バリュー」を参照)
    • 明確に定義された入力と出力がある
  • プロセスステップを明確にします*。「将来役立つ可能性がある」ステップを追加することは魅力的ですが、この方法は決して適切ではありません。自動化の各ステップは、プロセス全体の結果に関連します。各プロセスステップに次の特性があることを確認します。

    • 特定の詳細なタスクを実行する (「構成可能」を参照)
    • プロセスで定義された出力を生成するために必要 (必須ではないすべてのステップを削除)
    • 最小限のリソースで完了できる
    • 可能な場合はユーザーの入力を求めるのではなく、既存のシステムデータを利用する(「エンゲージメント」を参照)
    • ユーザーが基盤となるシステムのしくみを知らなくても理解できる入力オプションを提供します (ヘルプを参照)。

次のパターンとアンチパターンのリストは、Salesforce 組織での最適化が適切 (および不適切) であることを示しています。これらを使用して、作成前に自動化設計を検証したり、さらに最適化する必要がある自動化を特定したりできます。

Salesforce から入手できるプロセス自動化ツールについての詳細は、「Tools Relevant to Automated (自動化に関連するツール)」を参照してください。

運用ロジックは、プロセスを設計から実際の実装にどの程度効果的に変換するかを扱います。トランザクション量や実行中の同時インスタンス数の急増に関係なく、強力な操作ロジックを使用する自動化は引き続き適切に機能します。論理的に適切な自動化により、企業はより簡単に拡張して、より高い需要レベルで業務を行うことができます。自動化への強力な運用ロジックの組み込みは、システム全体の信頼性に直接関連します。

自動化が効果的に機能しないと、ユーザー エクスペリエンスとカスタマー エクスペリエンスが低下し、収益の損失と Customer Trust の低下の両方が発生する可能性があります。また、メンテナンスコストも高くなり、ボトルネックとなって関連プロセスが遅延し、システム全体のパフォーマンスの問題が発生する可能性があります。

自動化で効果的な運用ロジックを作成するには、次の点を考慮してください。

  • **自動化を作成する全員が適切な方法を確実に理解できるようにします。**どのような種類の自動化ツールでも、設計の選択肢は限られます。コードは、クリックベースのツールと同様に、エラーや不適切な実装の選択肢が発生しやすくなります。たとえば、ハードコードされた参照 ID の使用は、フローとコードの両方に現れるアンチパターンです。クリックベースのツールは、すべてのユーザーおよびすべてのユーザーがオートメーションを本番にリリースできるようにするライセンスとして捉えることはできません。オートメーションを作成するすべてのチームメンバーは、正しい方法でオートメーションを作成する方法を知っている必要があります。システム全体で有効な標準を定義して適用する方法についての詳細は、「読みやすさ設計標準」を参照してください。
  • すべての実行パスを明確に文書化します。自動化の使用が増加すると、潜在的なデータ量が増加するだけでなく、予定外のコールコンテキストも増加します。さまざまなオートメーションを呼び出す方法を理解し、複数のエントリポイントがあるすべてのオートメーションで適切なトランザクション制御 (「データ処理」を参照) が表示されることを確認する必要があります。たとえば、画面フローは一括データ読み込みでは実行されませんが、Apex トリガーおよびトリガー (および自動起動) フローはおそらく実行されます。実装時にどのような論理条件に対応する必要があるかを理解するうえで、自動化の計画済み実行パスと潜在的な実行パスを明確に文書化することは重要です。
  • すべてのデータ操作 (SOQL を含む) を**「一括」**します。すべてのデータ操作 (挿入、更新など) はコレクションに対して実行する必要があります。いつも例外なくこれは、操作を「一括処理」することを意味します。プラットフォームではシングルトンデータ操作をサポートできますが、シングルトンパターンの実装を許可しないでください。
  • 検索操作に SOSL を使用します。SOSL を介して返されたレコードに対してデータ操作を実行できないという誤解があります。SOSL 結果に対して DML を直接呼び出すことはできませんが、コードは SOSL 結果を解析し、DML または Database クラスメソッドで参照できるコレクションを作成できます。SOSL と SOQL の主な違いは、それぞれの戻り値のデータ型と、汎用検索またはワイルドカード検索への応答方法です。SOSL は複数の sObject 型に対して機能でき (そのため戻り値の型が異なります)、ワイルドカード検索や一般化された文字列検索を SOQL よりも優れたパフォーマンスで処理できます。
  • SOQL をデータ操作のように扱います。SOQL を使用してレコードを検索しないでください。SOQL を使用してデータ操作を絞り込みます。SOQL とデータ操作は、基礎となるリレーショナルデータベースのパフォーマンスに非常によく似た影響を与える可能性があります。SOQL では、データ操作を予期してデータベース行をロックする明示的 DML インジケータを渡すこともできます。スケーラブルな自動化を作成するには、SOQL を同様の適正評価で処理してください。具体的には、特殊で適切な形式の選択基準を使用せず、無関係な項目の参照を許可せず、WHEREステートメントロジックの項目と検索条件入力の間でデータ型を慎重に一致させる必要があります。また、一括処理されていないコンテキストや null または空白の検索条件に対してクエリが実行されないように、コードに適切な制御が必要です。
  • 同期操作は、ユーザーをリアルタイムで支援する作業のみに焦点を絞ります。プロセス最適化時に、ユーザーがリアルタイムまたはほぼリアルタイムで実行する必要がある内容と、非同期 (非同期) トランザクションに延期できる内容に関連するロジックを特定します。同期/非同期操作の設計に関する考慮事項についての詳細は、「データ処理」を参照してください。

次のパターンとアンチパターンのリストは、Salesforce オートメーションでの適切な (および不適切な) 操作ロジックを示しています。これらを使用して、作成前に自動化設計を検証したり、さらに最適化する必要がある自動化を特定したりできます。

拡張の計画に役立つ Salesforce から入手できるツールについての詳細は、「Tools Relevant to Automated (自動化に関連するツール)」を参照してください。

自動化 KPI は、自動化の経時的な影響を測定します。これらがないと、自動化が本当にビジネス価値を高めているか、ユーザーの意図しない複雑さを生み出しているかを判断する方法がありません。作成するすべての自動化は、明確で測定可能な KPI セットに関連付ける必要があります。

優れた KPI は、関連付けられた期間と共に測定可能な値で定義されます。例として、次のようなものがあります。

  • [X 個の数値] 1 か月あたりの作業時間の短縮
  • 手動データ入力による処理の失敗が週あたり [Y%] 減少

明確で測定可能な KPI ができたら、Salesforce の自動化によってそれらの KPI に対するレポートに関連するデータが生成されるかどうかと、どのように生成されるかも理解する必要があります。

次のパターンとアンチパターンのリストは、Salesforce の自動化に関する適切な (および不適切な) KPI を示しています。これらを使用して既存の KPI を検証したり、構築する前に KPI をより適切に識別する必要がある場所を特定したりできます。

KPI に関するヘルプとして Salesforce から入手できるツールについての詳細は、「Tools Relevant to Automated (自動化に関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

パターン & アンチパターンエクスプローラーでより多くのパターンを見つけて効率化します。

パターン アンチパターン
プロセス設計 組織内:
- 各フローは 1 つの特定の目的を果たす
- 各ステップで特定の詳細なタスクを実行
- フローは、メインフローとサポートサブフローで構成される階層構造で編成されます。
- すべてのユーザー入力にフロー内の明確な目的がある
- 既存のシステムデータを使用できない場合にのみ、ユーザーにデータの提供が求められます。
組織内:
- フローは複数の目的を果たし、コンテキストを提供するために追加の入力が必要
- フローには、データが使用されていない入力が必要です。
- 関連ステップのグループには、他のフローのステップのグループと重複する機能が含まれています。
- フローは、保存されているデータを代わりに使用できる場合にユーザーの入力を要求
Apex:
- 各クラスは 1 つの特定の目的を果たす
- 各方法で特定の詳細なタスクを実行
- すべての入力変数には、クラス内で明確な目的があります。
- 最小限のリソースでコードを実行
Apex:
- クラスは複数の目的を果たす
- メソッドが複数の ToDo を実行する、またはメソッドが属するクラスの明確な目的と一致しない ToDo を実行する
- 入力変数は実際にはメソッドで使用されません。
- データベースまたは外部システムからデータを不必要に取得するメソッド
運用ロジック フロー内:
- ハードコードされた値を参照する変数がない (レコードタイプ、ユーザーなど)
- すべての自動起動フローおよびプロセスでは、決定要素または一時停止要素、あるいはその両方を使用してエントリ条件を評価し、大量のデータに対する無限ループや実行を防止します。
- フロー(プロセスを含む)は、大量のデータ コンテキストでロジックをApexに渡す
- サブフローは、ビジネス全体で再利用する必要があるプロセスのセクションで使用されます。
フロー内:
- 変数の値がハードコードされている
- 一括データの読み込み前にフロー (プロセスを含む) を手動で無効化する必要がある
- フロー (プロセスを含む) で「未対応の例外」通知がトリガーされる
- 単純なフローでも、ガバナ制限に関連するエラーが発生することがよくあります。
- サブフローを使用するのではなく、フローの一部がフロー間で繰り返される
Apex:
- ハードコードされた値を参照する変数がない (レコードタイプ、ユーザーなど)
- すべてのワイルドカード条件が SOSL に表示されます。
- SOQL が try-catch でラップされている
- ループ内に SOQL が表示されない
- SOQL ステートメントは、次を含む選択的なステートメントです。
-- 類似の比較や部分的なテキストの比較は使用しない
-- 比較演算子は、主ロジックまたは唯一のロジックとして正のロジック (INCLUDESIN など) を使用します。
-- = NULL!= NULL の使用はまれで、常に正の比較演算子の後にある
-- LIMIT 1 ステートメントは表示されません。
-- no usage of ALL ROWS keyword
Apex:
- 変数の値がハードコードされている
- SOSL がワイルドカード選択条件で使用されることはほとんどありません。
- SOQL が try-catch でラップされていない
- SOQL がループ内に表示される
- SOQL ステートメントは、次を含む非選択的です。
-- 類似検索条件とワイルドカード検索条件が表示されます。
-- NOT 条件、NOT IN 条件を使用した比較は、主比較演算子または唯一の比較演算子として使用されます。
-- = NULL!= NULL 条件は主比較演算子または唯一の比較演算子として使用されます。
-- LIMIT 1 ステートメントが表示されます。
-- ALL ROWS キーワードが使用されている
設計標準およびドキュメント:
- 自動化の計画済み実行パスと潜在的な実行パスが明確になっている
- 自動化内の同期操作と非同期操作の使用事例が設計標準の一部として明確に示されている
設計標準およびドキュメント:
オートメーションの呼び出しが文書化されていない
- 同期操作と非同期操作の使用事例は対応していません。
KPIs ドキュメント内:
- すべてのオートメーションの出力は測定可能で期限付き
- KPI ごとに説明可能な関係者がリストされている
ドキュメント内:
- 自動化の KPI が存在しないか、メジャメントの期間が明確でない
- KPI には説明責任のある関係者がいない
レポートおよびダッシュボード内:
- KPI に関連するすべての総計値が 1 つ以上のレポートまたはダッシュボードに含まれている
レポートおよびダッシュボード内:
- KPI レポートが存在しないか、一部の KPI に関連する評価指標がレポートにない

データの整合性とは、システムが正確で完全なデータをどの程度適切に維持するかということです。Salesforce Platform では、個々の組織のリレーショナルデータベースに保存されているデータの整合性を保護するために設計された堅牢な組み込み処理ロジックが保持されます。健全な自動化を構築するための基本の 1 つは、Salesforce の組み込みデータ整合性動作を理解し、すべての自動化設計がこれらの動作に準拠していることを確認することです。

自動化設計の最大のアンチパターンは、Salesforce がすでに提供している強力なデータ整合性サービスを認識できず、これらのサービスを利用する標準機能を使用できないことにあります。データの整合性を保護および維持する自動化を設計するには、Salesforce の基本的な動作順序に精通している必要があります。

データの整合性をカスタム自動化に適切に拡張すると、次のことが可能になります。

  • 手動操作なしで一括処理や大量データに対する操作が可能
  • 必要に応じてユーザーセキュリティポリシーを適用し、必要に応じてシステムコンテキストに切り替えます。
  • 実行時にエラーが発生し、予測可能な復旧パスまたは障害パスを辿る。

適切なデータ処理とエラー処理により、Salesforce オートメーションにデータの整合性を高めることができます。

Salesforce で適切にデータを処理できるように設計するための最初のステップは、マルチテナントプラットフォームでトランザクションを処理する方法を理解することです。これには、レコードレベルのデータ操作中にデータの整合性を確保するために Salesforce Platform で使用される組み込みの実行順序動作の理解も含まれます。この動作の影響についての詳細は、「Salesforce アーキテクチャの基本」の「データベースの操作」を参照してください。

オートメーションのデータ処理が不適切である場合は、識別して完全に修正するのが最も困難なアンチパターンの 1 つになる可能性があります。プラットフォームの実行順序は再帰的で重複しているため、問題の発生場所を特定することが困難です。致命的なエラーをスローする、またはガバナ制限を超えるコードまたはフローの特定のセクションが、根本的なデータ処理問題の根本原因ではない可能性があります。

トランザクション認識は、Salesforce を使用して信頼性と拡張性を備えた自動化を構築するうえで重要です。つまり、自動化の各ステップは、プラットフォームで制御される実行順序に対する相対的な位置の Knowledge に基づいて設計され、機能を正しく実行して、情報を次のステップに正しく渡すことができます。

使用している自動化ツールに関係なく、適切なトランザクション認識は同様のパターンに従い、一般的な考慮事項が必要です。

  • すべての自動化は、任意の時点で大量のデータに対して予告なしに実行されることが想定されます。自動化には、一括または一括実行を可能にするパスが必要です(「拡張性」を参照)。
  • 同じトランザクションでシステムコンテキストデータ操作とユーザーコンテキストデータ操作を混在させないでください。
  • コンテキストの同期データ操作を予約し、コンテキストのすべてのアクションで非同期操作を使用します。
  • メッセージングと通知を使用して、非同期操作の結果に基づいてユーザーがデータを待機する必要があるアプリケーション内環境を作成しないようにします。

トランザクション認識以外にも、データ処理には 2 つ目の側面があります。それは、さまざまな実行コンテキストでロジックを実行するタイミングを知ることです。オートメーションをさまざまな実行コンテキストに分割する一般的な理由は次のとおりです。

  • 大量のデータ操作や複雑なデータ操作
    • 一括処理では、自動化で大量のデータが正しく処理されるとは限りません。自動化内のデータ操作の量がトランザクションあたりの制限を超える場合、大量データに固有の機能(バッチ Apex や Bulk 2.0 API など)を使用してデータ操作を実行する必要があります。これらは、大量のデータに適した個別のトランザクション制限があります。
    • レコード間で複雑なリレーション階層をトラバースしたり、複雑な再計算 (数式項目を含まない) を実行したりする必要があるデータ操作を一括で実行すると、トランザクションあたりの制限を簡単に超える可能性があります。システムで後続のアクションを完了するために必要な関連データ操作または SOQL の観点から、1 つのレコードの更新がどの程度「うるさい」かを検討します。
    • 自動化のチェーン全体に関与する sObject の種別では、「混在 DML」エラーを回避するために、データ操作を個別のトランザクションに分割する必要がある場合があります。
  • ユーザーまたはシステムコンテキストで実行する必要があるロジック
    • Salesforce Platform は、ユーザーコンテキストでの共有と表示を適用します。オートメーションのユーザーの権限レベルを超える操作を実行する必要がある場合、それらの操作がシステムコンテキストで実行されることを確認する必要があります。
    • さまざまなツールは、さまざまなコンテキストで実行されるか、実行されません。
      • Apex はデフォルトでシステム コンテキストで実行されます。Apex 動作でユーザー レベルの共有ルールを適用するかどうかと適用方法を制御できます。これを行うには、Apex クラス定義で sharing キーワードを使用します。
      • フローには 1 つのデフォルト動作はありません。フローは、フローの起動方法に基づいてユーザーコンテキストまたはシステムコンテキストで実行されます。システムコンテキストで共有を適用するオプションがあります。
      • プロセス (つまり、プロセスビルダーで作成されたオートメーション) は、共有に関する考慮事項なしでシステムコンテキストで実行されます。(注意:フローを使用してローコードの自動化を作成することをお勧めします。
  • 非同期で実行する必要があるロジック
    • 外部システム操作 - 外部データにアクセスする同期コールアウトまたはアクションは、プラットフォームのロールバック動作に含まれません。これらの動作を利用するには、外部システムを含むアクションを個別のトランザクションに配置する必要があります (非同期 Apex メソッド、非同期パス、または呼び出し可能アクションを使用)。
    • イベントおよびメッセージング - データ操作に関連するイベントまたはメッセージのフローを制御する (およびプラットフォームのロールバック動作を利用する) には、非同期 Apex メソッドを使用して、メッセージングまたはイベントに関連するすべてのアクションをアフターコンテキストに配置します。

次のパターンとアンチパターンのリストは、Salesforce オートメーションでの適切な (および不適切な) データ処理を示しています。これらを使用して、作成前に自動化設計を検証したり、データ処理を改善するためにリファクタリングする必要がある自動化を特定したりできます。

自動化でのデータ処理に Salesforce から使用できるツールについての詳細は、「Tools Relevant to Automated (自動化に関連するツール)」を参照してください。

エラー処理は、データの整合性を保つために重要です。また、強力なエラー処理により、システムの拡張性と経年劣化を回復力を高めます。

オートメーションで不適切なエラー処理が行われると、次の原因が考えられます。

  • レコードの不一致やその他のデータ整合性の問題
  • ユーザーや他のシステムへの不正確な通知の送信
  • 手動または反復処理による時間とリソースの浪費
  • システムに対する全体的なTrustの欠如

オートメーションのエラー処理では、実行中のプロセスに、情報のエラーを解析し、エラー情報に基づいて次のステップに関するロジックにアクセスして、正しいパスに従う機能を付与する必要があります。これらの機能は、すべての自動化で何度も構築する必要はありません(最適化アンチパターン)。代わりに、システムのすべてのオートメーションは、関連するエラー処理コンポーネントに接続できる必要があります。

適切なエラー処理コントロールをオートメーションに組み込むには、次の質問をします。

  • 「致命的」エラーとは?
  • 「回復可能な」エラーとは?
  • ユーザーアクションによってトリガーされるオートメーションの場合、変更を確定する前にエラーを検出してユーザーに通知する方法は?

これらのエラーの処理方法を決定したら、効果的なエラー処理をオートメーションに組み込むことができます。次のパターンとアンチパターンのリストは、Salesforce オートメーションでの適切な (および不適切な) エラー処理を示しています。これらを使用して、作成前に自動化設計を検証したり、エラー処理を改善するためにリファクタリングする必要がある自動化を特定したりできます。

エラー処理用に Salesforce から入手できるツールについての詳細は、「Tools Relevant to Automated (自動化に関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

パターン & アンチパターンエクスプローラーで、データの整合性に関するより多くのパターンを検出します。

パターン アンチパターン
データ処理 データ辞書:
- すべてのデータソースとデータレークオブジェクトの項目レベルのデータと優先順位付けロジックが存在する
- データレークオブジェクトからデータモデルオブジェクトへの項目の対応付けが存在する
データ辞書:
- データソースとデータレークオブジェクトの項目レベルデータと優先度ロジックは含まれません。
- データレークオブジェクトからデータモデルオブジェクトへの項目の対応付けは含まれません。
Apex:
- すべての同期 DML ステートメントまたはデータベースクラスのメソッドがトリガー実行のコンテキストで実行される
-非同期Apex呼び出しでは、キュー可能を使用してトランザクション間で複雑なDMLを「チェーニング」します。
-バッチApexは、大量のデータに対してのみ使用されます。
- @future Apex は、コールアウトまたはシステム オブジェクト DML で慎重に使用されていません。
Apex:
- DML ステートメントは、トリガーのコンテキストで呼び出されるコードに定期的に表示されます。
- 非同期 Apex はほとんど使用されません。
- 次のような非同期 Apex 機能が任意に使用されます。
-- Future メソッドと Queueable Apex が一貫性がないか、同じ意味で使用されています。
-- データベース操作には、必要に応じて実行を一括処理 Apex に渡すための明確で一貫したロジックがない
フロー内:
- ユーザーコンテキストで起動されるすべてのフローは、すべてのシステムコンテキストトランザクションをサブフローに抽象化します。サブフローは、[一時停止] 要素の後に一貫して配置され、新しいトランザクションを作成します。
- (モノリスフロー内で複数のサブフローを呼び出すのではなく) Orchestrator を使用して関連データ操作の複雑なシーケンスを作成する
- すべてのレコードトリガーフローにトリガー順序値が入力されている
- 外部システムコールアウトまたは実行時間の長いプロセスが含まれるフローで非同期パスが使用されている
フロー内:
- 大規模なモノリシックフローが、関連するデータ操作の複雑なシーケンスを調整しようとする (サブフローの有無にかかわらず)
- レコードトリガーフローでトリガー順序属性がまったく使用されていない、またはトリガー順序値が一貫して使用されていない
- 非同期パスが一貫して使用されていない、またはまったく使用されていない
組織内:
- ID 解決調整ルールは、データ辞書の優先度設定ロジックに従います。
組織内:
- ID 解決調整ルールがデータ辞書の優先度ロジックに従っていない
エラーハンドリング Apex:
- コードは、すべての DML、SOQL、コールアウト、およびその他の重要なプロセスステップを try-catch ブロックでラップします。
-カスタム例外を使用して高度なエラーメッセージとロジックを作成
- 非同期コンテキストと一括コンテキストでは、DML の代わりにデータベースクラスメソッドが使用される
- データベースクラスメソッドは、すべてのデータ操作 (DML の代わりに) で排他的に使用できます。
Apex:
- DML、SOQL、コールアウト、またはその他の重要なプロセスステップが一貫して try-catch ブロックでラップされていない
- 本番コードに System.debug ステートメントが表示される (コメントアウトされない)
- Database クラスのメソッドが使用されていない
- データ操作は DML のみで行われます。
Lightning Web コンポーネント (LWC) の場合:
- JavaScript は、すべてのデータ操作と重要なプロセスステップを if ()/else if () ブロックでラップします。
- すべての @wire 関数は、API で提供されたデータおよびエラープロパティを使用します。
- すべての if (error)/else if (error) ステートメントには、エラーを処理して情報メッセージを提供するロジックが含まれます。
LWC の場合:
- JavaScript では、データ操作または重要なプロセスステップを含む if ()/else if () ブロックを一貫して使用しません。
- @wire 関数は、API で提供されたデータおよびエラープロパティを使用しません (または、一貫して使用しません)。
- まったく使用していない場合、if (error)/else if (error) ステートメントには、エラーを処理して有益なエラーメッセージを提供するロジックが実際には含まれていません。
Aura の場合:
- JavaScript は、すべてのデータ操作と重要なプロセスステップを try-catch ブロックでラップします。
- try-catch ブロック内では、ネイティブの JavaScript エラーが throw ステートメントで使用されます ($A.error() は使用されません)。
- リカバリ可能なすべてのエラーロジックが catch ステートメント内に表示され、明確なユーザーメッセージが提供される
Aura の場合:
- JavaScript では、データ操作と重要なプロセスステップが一貫して try-catch ブロックでラップされない
- コンポーネントは $A.error() を使用します。
- リカバリ可能なエラーロジックが catch ステートメント内に一貫して表示されず、ユーザーへのエラーメッセージが明確でない
フロー内:
- 画面フローでは一貫して障害コネクタを使用してユーザーにエラーを表示します。
画面に表示されるエラーに対してカスタムエラーメッセージを設定する
- データ操作、コールアウト、その他の重要な処理ロジックを含むフローには、すべての主要なアクションの障害パスがあります。
フロー内:
- フローで障害パスが一貫して使用されていない、またはまったく使用されていない
- カスタムエラーメッセージが使用されないため、ユーザーにはデフォルトの「このフローで未対応の障害が発生しました」メッセージが表示されます。

自動化のコンテキストでのビジネス価値の概念は、プロセスがビジネス関係者に測定可能なプラスの影響をどの程度もたらすかということです。プロセスの自動化によって、反復的で価値の低いタスクに費やす時間を短縮できることが理想的です。また、エラーが発生する可能性のある手動処理作業を排除することで、データの整合性を高めることもできます。プロセス設計と同様に、実際のビジネス バリューを促進する自動化を特定して提供するためには、基本的な検出やビジネス分析以上の作業が必要です。

ビジネスユーザーが要求したすべてのプロセスを、バックログ (またはチケットキュー) に表示される順序で、または組織の政治的要因に基づいて自動化することが、ビジネスに価値を提供する最善の方法と思われる場合があります。これにより、2 つの関連する問題が生じる可能性があります。つまり、最適な順序で自動化を構築することと、間違った自動化を完全に構築することです。1 つ目の問題は、優先順位付けが不十分で、価値の高いプロセスが必要なときに実装されず、成長が鈍化する可能性があります。2 つ目の問題は、間違った自動化を構築することで、価値の高い自動化のデリバリが遅延するだけでなく、時間の無駄遣いや不要なコストが発生し、デリバリチームのストレスが高まることです。

KPI と優先順位付けに重点を置くことで、より大きなビジネス価値を提供できます。

ツール説明効率データ整合性ビジネス上の価値
Apex バッチレコードをまとめて管理可能なチャンクとして処理するXX
Apex Future メソッドApex メソッドをバックグラウンドで非同期に実行XX
Apex Queueing Apex ジョブをキューに追加して監視するXX
Apex SchedulerApex クラスを指定された時間に非同期で実行するXX
承認レコードを承認するために必要なステップを指定するXX
非同期 ApexApex コードを非同期で実行XX
自動アクション項目自動更新、メール送信、その他のアクションをバックグラウンドで実行するXX
Einstein Next Best Action適切なおすすめを適切なタイミングで適切なユーザーに表示XX
メールアラート自動メールの作成と送信XX
エスカレーションアクションケースのエスカレーションで実行する自動アクションを指定するXX
項目自動更新自動化に基づいて項目値を更新するXX
Flow Builderポイント & クリックインターフェースを使用した自動化の構築XX
フロー拡張保存されている変数にフローのコンポーネント入力としてアクセスX
フローテンプレートライブラリテンプレートを使用した業種固有のフローの設計XX
フロートリガー複雑なビジネスプロセスの自動化X
呼び出し可能なアクションApex 機能をフローに追加するXX
オーケストレーター複数ステップの自動化の作成と管理XX
送信メッセージ受信確認と再試行を使用して自動化プロセスから情報を送信する X
フローを使用したプラットフォームイベントの公開ユーザー操作と自動化による行動の公開X
Query Optimizer選択性とインデックスを使用して、クエリ、レポート、リストビューのパフォーマンスを向上XX
Salesforce フローFlow Builder を使用した宣言型プロセスの自動化の作成XX
フローを使用した通知の送信SMS、WhatsApp、Facebook Messenger でメッセージを送信XX
プロセスを使用した通知の送信SMS、WhatsApp、Facebook Messenger でメッセージを送信XX
SOQL FOR UPDATE 修飾子競合状態とスレッドの安全性の問題を回避するためにレコードをロックするX
Strategy Builder レコードページに表示するおすすめを特定するXX
サブフロー再利用によるフローの複雑さの軽減X
フローを使用したプラットフォームイベントの登録オートメーションを介して公開されたメッセージの受信X
ToDo アクション自動化によってユーザーに付与される割り当ての詳細を決定するX
リソース説明効率データ整合性ビジネス上の価値
Apex 実行ガバナおよび制限Apex ランタイムエンジンによる制限の適用方法XX
一括管理リソース一括処理ジョブの作成、管理、スケジュール、監視XX
SOQL および SOSL のベストプラクティス大量のデータを使用するアプリケーションのクエリパフォーマンスを向上X
設計標準テンプレート組織の設計標準を作成するXXX
トランザクションでのフローの一括処理コレクションに対して操作するフローを設計するXX
フローデータに関する考慮事項バッチデータのスケジュールトリガーフローについてXX
フローのデバッグフローのテストとトラブルシューティングX
要求の処理方法Salesforce でジョブをすばやく処理して失敗を最小限に抑える方法XX
KPI Spreadsheet Template特定の指標のビジネス価値を判断するXX
呼び出し可能なアクションからの外部システムへのコールアウトApex を使用したフローからの外部システムのコールX
混在 DML 操作同じトランザクションの DML で一緒に使用できる sObject を把握するXX
実行順序挿入、更新、更新/挿入のイベントの順序を理解するXX
クエリプランに関する FAQ大量のデータが含まれるクエリを最適化するXX
スケジュールトリガーフローに関する考慮事項スケジュールトリガーフローの特殊な動作についてX
トランザクションコントロール現在のデータベースの状態を指定するセーブポイントを生成するXX
フローが失敗するとどうなるかフローでのエラー処理についてXX
ワークフローの自動化のベスト プラクティス ガイドSalesforce オートメーションの使用開始XXX
Working with Very Large SOQL Queries (非常に大きい SOQL クエリの処理)より効率的な SOQL クエリの作成X

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくためのアンケートにご協力ください。また、今後の展望についてもお聞かせください。