レコードが Sales Cloud から Journey Builder に挿入されない

• どのバージョンの Marketing Cloud Connect パッケージを使用していますか? 
  • 既知のバグを回避する一番の方法は、インストールされたパッケージの最新リリースを常に使用するようにすることです。Sales Cloud で [設定] をクリックすると、バージョンを確認できます。次に、[ビルド] > [インストール済みパッケージ] の順に移動します。このパッケージは「Marketing Cloud」という名前です。最新バージョンはこちらのページに記載されています。
• Marketing Cloud API ユーザーは、更新/作成されるオブジェクト/レコードにアクセスできますか?
  • Marketing Cloud API ユーザーは、Sales Cloud と Marketing Cloud のインテグレーションを維持するために使用されるため、このユーザーには、インテグレーションを通じて Journey Builder に挿入されるレコードへのアクセス権が必要です。これは、Marketing Cloud API ユーザーを Salesforce ユーザー (通常は、各オブジェクトに適切な権限を持つ専用の Salesforce System ユーザー) と統合することによって行われます。この Salesforce ユーザーにシステム管理者ロールを提供すると、簡単で確実にアクセス権を持たせることができます。
• 接続している Salesforce Org で、テナント固有の OAuth エンドポイントが有効になっていることを確認します。詳細は、「Marketing Cloud Connect でテナント固有の OAuth エンドポイントを有効にする」を参照してください。
• 関連オブジェクトの条件が適用されていない、最も単純なエントリ条件でレコードを挿入できますか? 
  • 場合によっては、エントリ条件が排他的すぎたり、互いに矛盾する 2 つの検索条件が含まれていたりすることがあります。たとえば、主オブジェクトがリードに設定され、「Lead:Status」が ['Pending' AND 'Closed'] に更新されたら挿入するようにエントリ条件が設定されている場合、これら 2 つの条件ではレコードの挿入が許可されません。リードの「Status」はいずれか一方にしかなり得ないため、AND 演算子を OR 演算子に置き換えれば、挿入が成功する可能性が高まります。 
  • ライブリリースに必要な条件は堅牢で多くの検索条件を含みますが、レコードの更新後または作成後に挿入が実行されない場合は、1 つの検索条件を除いてすべての条件を削除してみます。1 つの検索条件で挿入が成功したら、徐々に複雑な検索条件に移行します。このような方法を採れば、問題のある検索条件を明確に特定できます。これは、関連オブジェクト条件アプリケーションからも適用できます。 
  • 「Update/Create」アクションがフォーム登録または別のプロセスによって完了する場合は、プロセス完了後に「Updated/Created」レコードにエントリ条件を満たすために必要なデータが含まれていることを確認します。場合によっては、必要なデータの一部だけを持つレコードの「Update/Create」を別プロセスが実行し、レコードを完成させるために追加プロセスの実行が必要になります。
    • このシナリオの例としては、ビジネスに関する空白のページをリクエストする顧客のフォーム登録が、午後 6 時 (東部標準時間) に発生するケースが考えられます。登録時には、このような顧客は CRM にリードとして追加されます。リードのレコードには、リクエストに関する詳細が含まれます。このレコードは、午後 6 時より後 (東部標準時間) に挿入されると予想されます。しかし、プロセスビルダーには、毎朝午前 5 時 (東部標準時間) に新規作成されたリードを更新するスケジュール済みプロセスがあります。このプロセスによって更新される項目の 1 つは、ジャーニーのエントリ条件として含まれます。そのため、フォームが登録された直後ではなく、午前 5 時過ぎ (東部標準時間) まで挿入が期待できなくなります。 
  • 「条件」に含まれる Sales Cloud 項目のデータ型は、挿入が成功するかどうかに影響します。数式項目のデータ型は「Update」に基づいてトリガーされません。数式型は他の項目に依存するため、「not qualifying (非対象)」から「qualifying (対象)」への状態変更を満たすことができません。この状態変更は、「Update」アクションの対象となるために必要です。数式項目のデータ型は、「Create」が使用されるアクションの場合、挿入をトリガーします。この状態変更については、詳細を後述します。
• 「アクション」の選択が挿入のトリガーで果たす役割。
  • この例では、次の Salesforce エントリイベント設定を使用します。

Object: Opportunity Who : LeadID (Lead) Action : Updated Criteria : 'Opportunity:Lead:FirstName' equals 'James' AND ('Opportunity:Status' equals 'Won' OR 'Opportunity:Status' equals 'Pending')

• ジャーニーを作成し、Salesforce のデータエントリイベントを設定した後に、James Dean のリードに関連付けられた商談を作成します。商談が作成されると、ステータスは「Pending」となります。「アクション」が Update に設定されているため、挿入はトリガーされません。つまり、作成時にエントリ条件を満たしたレコードは、「Update」アクションが原因となって評価されないことになります。営業チームは、James Dean に関連付けられた商談のクローズに向けて取り組んでおり、それに成功しました。James の商談ステータスが「Won」に更新されます。この場合、商談レコードは対象の状態 ('Opportunity:Status' equals 'Pending') で始まり、その後対象の状態('Opportunity:Status' equals 'Won) に更新されたため、挿入はトリガーされません。これは、「Update」アクションが挿入をトリガーするために重要です。レコードは、最初は非対象であり、次に対象に更新されなければなりません。リードに関連付けられた商談の「Opportunity:Status」が「Under Review」で始まり、後に「Won」に更新された場合、「Opportunity:Status」が「Under Review」から「Won」に更新されると、挿入が発生します。
• 引き続き同じエントリイベント設定と James Dean のリードを使用します。このシナリオでは、James がジャーニーに 2 回挿入されるはずです。1 回目が商談ステータスが「Pending」になったときで、2 回目が「Won」に更新されたときです。James の商談を作成すると、ステータスは「Waiting」となります。これでは、挿入はトリガーされません。数日が経ち、商談レコードが「Pending」に更新されました。これで James がジャーニーに挿入されます。チームは商談を成立させるために努力を続け、最終的に成立させました。これで、商談ステータスは「Won」に変更されました。挿入は実行されません。Update が挿入のトリガーとなるための重要な要件は、レコードが非対象になり、その後対象の状態に更新されることですが、その処理は発生していません。商談はステータスが「Pending」であり、その後「Won」に更新されました。どちらも対象であるため、システムはこれを Update として登録しません。エントリ条件の中では、各検索条件コンポーネントは 1 つの検索条件にグループ化されていると考えることができます。この検索条件に対してレコードを送信すると、1 (true) または 0 (false) が返されます。レコードが対象であれば、1 が送信されます。レコードは更新されたが、引き続き対象である場合は、1 が送信されます。更新が Update のエントリ条件アクションを満たすためには、それぞれの 1 の間に 0 が渡されなければなりません。このように更新が複数挿入される必要がある場合は、商談ステータスが「Won」と、商談ステータスが「Pending」の 2 つのジャーニーを作成します。 

その他のリソース:  

• Salesforce データがジャーニーに挿入されない場合にデバッグログを解析する
• Journey Builder の判断分岐および他のフィルターベースのアクティビティ
• Journey Builder パフォーマンスの最適化