Salesforce と外部分析プラットフォーム間のほとんどのエンタープライズインテグレーションパイプラインは、カスタムコードに依存します。何かが壊れるまで動作し続ける。スキーマドリフト、API の枯渇、物理削除のギャップには、絶え間ないエンジニアリング介入が必要です。企業がアジャイルな市民開発者対応アーキテクチャに移行すると、このモデルはボトルネックとなります。分析チームはエンジニアリングのスプリントを待って下流スキーマに Salesforce 項目を追加し、夜間の読み込み失敗により月曜朝の報告が遅れるほか、単純な設定変更でもコードレビューとリリースが求められます。

Salesforce ネイティブの分析およびビジネスインテリジェンスプラットフォームである CRM Analytics を使用すると、企業は Salesforce エコシステムから離れることなく、データの探索、対話型ダッシュボードの構築、AI 主導のインサイトの解明を行って、この問題を解決できます。この機能の中心となるのは、プラットフォームにネイティブに組み込まれている宣言型のローコードデータ同期機能 (CRM Analytics SyncOut と CRM Analytics SyncIn) です。

CRM Analytics SyncOut は、増分読み込み用の変更データキャプチャキャプチャ (CDC) と、完全に削除されたレコードにフラグを設定する組み込みの物理削除追跡を使用して、設定されたスケジュールに従って Salesforce レコードを外部データストアに移動します。CRM Analytics SyncIn は外部データを Salesforce に戻し、Bulk API 2.0 を使用して列をオブジェクト項目に対応付けてレコードを更新します。 どちらも、Salesforce の [設定] ですべて設定します。パイプライン、ステージングスクリプト、カスタム監視はありません。システム管理者は 1 つの設定セッションで同期ジョブを設定します。実行、再試行、エラーログ、スキーマの対応付けはプラットフォームで自動的に処理されます。

このガイドでは、パターン、パターンを使用する状況、Snowflake を使用した実装方法、特定のインテグレーションの問題に適合するかどうかを判断するアーキテクチャ上の考慮事項について説明します。

ライセンスノート: CRM Analytics SyncIn および SyncOut は、CRM Analytics ライセンスアドオンのない Salesforce 基本エディションでは使用できません。これらの機能に依存する同期アーキテクチャを設計する前に、ライセンスエンタイトルメントを確認してください。

データインテグレーションは、企業アーキテクチャにおいて最も摩擦の大きいサーフェスの 1 つです。通常、Salesforce から分析プラットフォームへのカスタム ETL パイプラインには、認証用の接続アプリケーション、SOQL 抽出用のスケジュール済みジョブ、データ型を調整するための変換レイヤー、一括読み込み用のステージングエリア、障害を検出するための監視レイヤーが必要です。カスタムコードの各コンポーネントは障害ポイントを表します。

この摩擦によるコストは時間とともに増大します。Salesforce のスキーマドリフト (名前が変更された項目、新しい選択リスト値、変更された API 参照名) は、通知なしでパイプラインを中断します。ピーク時の API の枯渇により、抽出が停止されます。物理削除されたレコードが対象テーブルに表示されないため、ダウンストリーム分析でライブとして処理される古いデータが残されます。エンジニアリングチームは、日常的なデータ操作のボトルネックになります。

CRM Analytics SyncIn と SyncOut によって、動作モデルが変更されます。構成によってコードが置き換えられます。プラットフォームは、実行、エラー処理、スキーマの対応付け、オブザーバビリティを担当します。管理者は、開発チケットを引き上げることなく同期ジョブを定義、変更、監視できます。

この新しい運用モデルにより、インテグレーション設計から運用同期までの時間が短縮され、エンジニアリングのオーバーヘッドが軽減され、カスタムコードのメンテナンスではなくプラットフォームの制約内で拡張できるインテグレーションモデルが実現されます。

SyncIn と SyncOut は、CRM Analytics データ同期の 2 つの方向モードです。SyncOut は、Salesforce レコードを外部プラットフォームに移動します。SyncIn では、外部レコードが Salesforce に取り込まれます。どちらもカスタムコードを必要としない宣言型設定モデルで動作します。

宣言型構成とは、すべての同期動作をSalesforceの[設定]のポイント アンド クリックUIで定義することです。取得元オブジェクト、取得先テーブル、項目の対応付け、同期スケジュール、同期モード、検索条件はすべて設定メタデータを使用して設定されます。プラットフォームは、そのメタデータから実行計画を取得し、エンドツーエンドで管理します。

完全同期と増分同期では、実行ごとに移動するデータを制御します。完全同期では、すべての実行で検索条件に一致するすべてのレコードが照会されます。増分同期では、CDC を使用して、前回の実行以降に変更されたレコードのみを照会します。増分同期は、API 消費と同期期間を大幅に短縮するため、大規模オブジェクトには推奨されるモードです。

変更データキャプチャ (CDC) は、オブジェクトへの項目レベルの変更をイベントストリームとして記録する Salesforce Platform の機能です。SyncOut は CDC を使用して、テーブル全体のスキャンを実行せずに作成、更新、削除を検出します。同期設定から参照するには、Salesforce の [設定] でオブジェクトごとに CDC を有効にする必要があります。

物理削除追跡は、Salesforce から外部 ETL で最も根強い問題の 1 つを解決します。Salesforce でレコードが物理削除されると、そのレコードは標準 SOQL クエリに表示されなくなります。明示的な追跡を行わない場合、外部プラットフォームはレコードが削除されたことを認識することはありません。SyncOutの物理削除追跡を有効にすると、対象テーブル内の削除されたレコードにDEL_FLAG = 'Y'フラグが付けられ、ダウンストリームシステムに古いデータを絞り込むための信頼性の高いシグナルが提供されます。

同期頻度は 15 分から毎週まで設定できます。選択は、データの新鮮度、API 消費量、Snowflake ウェアハウスの計算コストのトレードオフです。15 分同期は、運用ダッシュボードにおいてほぼリアルタイムに近い動作を実現します。一方、日次同期は一括処理レポートのワークロードに適しています。

ガバナ制限同期ジョブ設計: Salesforce API 要求の制限 (Unlimited Edition では 24 時間あたり 15,000 コール)、Bulk API 2.0 のバッチサイズである 10,000 件のレコード、およびトランザクションあたりの SOQL クエリ行の制限である 50,000 件によって、同期ジョブのサイズとスケジュール方法が決まります。プラットフォームではチャンクとページネーションが自動的に処理されますが、アーキテクトは組織で実行されているすべての同期ジョブで制限されたヘッドルームを考慮する必要があります。

Snowflake は、Salesforce CRM Analytics とのデータ同期の主要な対象およびソースです。これは、バッチおよび増分データ移動がエンドツーエンドでどのように機能するかを示す具体的な例となります。

このセクションでは、Snowflake を外部分析プラットフォームとして使用する CRM Analytics SyncOut および SyncIn の実装の概要について説明します。各方法、共有認証モデル、セキュリティフレームワーク、主要なプラットフォームの考慮事項、オブザーバビリティプラクティスについて説明します。

この SyncOut 設定では、Salesforce は CRM Analytics SyncOut を使用してレコードを Snowflake に転送します。プラットフォームは SOQL を使用してデータを抽出し、種別変換を自動的に処理して、設定されたスケジュール (15 分から毎週) で Snowflake テーブルに読み込みます。具体的な読み込みセマンティックについては、最新の Salesforce および Snowflake のドキュメントを参照してください。

SyncOut アーキテクチャ

この SyncIn 設定では、Salesforce は CRM Analytics SyncIn を使用してデータを Salesforce に取り込みます。プラットフォームはステートメント API を使用して Snowflake を照会し、Bulk API 2.0 を使用して結果を Salesforce に更新/挿入します。 大きな結果セットは、API 制限内に収まるように自動的にページ分割されます。同期は、15 分から毎週の設定済みスケジュールで実行されます。

SyncIn アーキテクチャ

Salesforce 同期では、Snowflake と安全に接続するための複数の認証方法がサポートされています。企業インテグレーションの主なアプローチは、キー・ペア（秘密鍵）と委任された OAuth 2.0 です。

方法 1: キーペア (非公開鍵) 認証: キーペア認証は、CRM Analytics SyncIn や SyncOut など、システム間の自動データ移動に推奨される方法です。認証では、パスワードや更新可能なトークンではなく JSON Web トークン (JWT) が使用されるため、トークンの更新を必要としない無人のスケジュール済みジョブに適しています。

  • Salesforce Certificate: 非公開鍵を生成し、Salesforce Certificate and Key Management に安全に保存します。
  • 外部/指定ログイン情報: JWT エクスチェンジを使用するように設定されます。Salesforce は、保存された秘密鍵を使用して送信接続要求に署名します。
  • Snowflake ユーザー公開鍵: 一致する公開鍵は、専用の Snowflake サービスアカウントに直接割り当てられます (ALTER USER CRM_ANALYTICS_SYNC_USER SET RSA_PUBLIC_KEY = ’…’ など)。次に、Snowflake はこの鍵を使用して受信 JWT 署名を検証します。この方法にはセキュリティインテグレーションは必要ありません。

方法 2: 代理 OAuth 2.0 認証: または、Salesforce は OAuth ハンドシェイクを使用して認証できます。主要なコンポーネントは次のとおりです。

  • 認証プロバイダー: Snowflake Security Integration から取得したクライアントログイン情報を使用して、Snowflake との OAuth ハンドシェイクを管理します。
  • 外部ログイン情報: OAuth トークンを Salesforce 内に安全に保持し、同期コールアウトに自動的に挿入します。
  • 指定ログイン情報: Snowflake エンドポイント URL (例: https://<account>.snowflakecomputing.com) を定義し、外部ログイン情報を参照します。
  • Snowflake Security Integration: Snowflake で Salesforce を信頼済み OAuth クライアントとして登録します (OAUTH_CLIENT = CUSTOM)。許可されるリダイレクト URI を定義し、更新トークンを有効にします。

設定の連動関係: 選択した方法に関係なく、これらのコンポーネントは同期設定をエンドポイントに接続する連動関係チェーンを形成します。関連する Salesforce プロファイルに指定ログイン情報へのアクセス権を付与する必要があります。このアクセス権がないと、他のすべての設定に関係なく認証エラーで同期ジョブが失敗します。

バックグラウンド同期は、1 つのインテグレーション ID に依存します。

  • 専用サービスアカウント: 同期に必要なデータベース、スキーマ、およびテーブルのみに範囲が限定された最小権限のロールを使用して、専用の Snowflake サービスアカウントを作成します。
  • 詳細な権限: SyncOut の場合、このロールには対象テーブルに対する INSERT、UPDATE、および SELECT が必要です。ACCOUNTADMIN、SECURITYADMIN、SYSADMIN などの高権限ロールは使用しないでください。
  • ガバナ制限およびチャンク: SyncOut 抽出時に、Salesforce SOQL ガバナ制限に準拠するように大きな結果セットが自動的にチャンクされます。SyncIn は、データ量を効率的に管理するために自動ページネーションを使用して Snowflake ステートメント API から大きな結果セットを取得します。
  • 変更データキャプチャ (CDC): 増分 SyncOut では、Salesforce CDC イベントストリームを使用して、作成、更新、削除されたレコードを識別します。物理削除追跡が有効になっている場合、削除された Salesforce レコードは削除されませんが、Snowflake でDEL_FLAG = 'Y'のフラグが付けられます。
  • 更新/挿入制約: SyncInでは、Bulk API 2.0を使用してデータをSalesforceに再度読み込みます。そのためには、更新/挿入キーとして動作するように、対象 Salesforce オブジェクトで外部 ID 項目を設定する必要があります。
  • 設計ガイダンス: 常に未加工のテーブルではなく選定された Snowflake ビューから同期します。ビューでは、行の事前絞り込み、列の選択、ビジネスロジックの適用が可能になり、適用される事前絞り込みに比例してデータ量、同期期間、Snowflake ウェアハウスの計算コストを削減できます。

同期を実行するたびに、データ移動を検証する包括的な監査履歴が生成されます。Sync Job Monitor (同期ジョブ監視) ダッシュボードでは、SyncIn と SyncOut の両方のリアルタイムの状況、処理されたレコード件数、実行時間、詳細なエラーログが提供されます。Snowflake 側では、Salesforce が送信したすべてのクエリが Snowflake クエリ履歴に記録され、実行遅延、スキャンされた行数、および倉庫のコンピューティング使用状況が完全に可視化されます。さらに、アーキテクトは同期実行メタデータ (タイムスタンプ、レコード件数、エラー) を取得するために専用の Snowflake 監査テーブルを定義します。これらはプラットフォームによって自動的に生成されません。エンド ツー エンドの検証では、両方のプラットフォームでレコード数を比較します。SyncOutの実行ではSnowflake(WHERE DEL_FLAG = 'N')のアクティブ レコードを検証し、SyncInの実行ではSalesforceターゲット オブジェクトの数を元のSnowflakeソース ビューと直接比較します。

CRM Analytics SyncIn および SyncOut は、次の場合に使用します。

  • 双方向同期が要件: データは、SyncIn を介して Salesforce に流れ、SyncOut を介して外部プラットフォームに流れます。
  • 物理削除追跡: SyncOut の組み込みフラグ設定により、カスタム調整ロジックなしで歴史的に複雑な ETL の問題を解決できます。
  • CDC ベースの増分同期が可能: 大規模な Salesforce オブジェクトの場合、CDC は API 消費と同期期間をフルスキャンと比較して大幅に削減します。
  • スケジュール済みバッチ同期はレイテンシ要件を満たします。最小同期頻度は15分で、運用ダッシュボードとほぼリアルタイムの分析レポートに適しています。
  • 低い運用オーバーヘッドが優先されます。組み込みダッシュボードでは、カスタム ログやアラート インフラストラクチャを使用せずに同期を完全に表示できます。また、宣言型の設定UIでは、管理者は開発チケットを調達することなく同期ジョブを定義、変更、監視できます。

次の場合は、このパターンを使用しないでください。

  • 複数テーブルの結合、JSON 解析、Snowflake ビューでの高度なビジネスロジックの処理、または同期の前または後の専用の変換レイヤーなど、複雑な変換が必要です。
  • 15分未満のレイテンシが必須: リアルタイムのユースケースでは、Platform Events または Streaming APIs を利用してください。
  • 非常に大量のストリーミング ワークロードが対象範囲:1時間あたり数百万のトランザクションがあるオブジェクトは、専用のストリーミング パイプライン(Kafka、プラットフォーム イベント)によって適切に処理されます。
  • カスタムエラー処理ロジックが必要プラットフォームには、標準の再試行とエラーログ記録が用意されています。複雑な再試行パターンまたはカスタム アラートには、Apexまたは外部オーケストレーションが必要です。
  • マルチ組織同期またはクロスクラウド同期: CRM Analytics SyncIn および SyncOut は、1 つの Salesforce 組織内で動作します。複数組織のシナリオでは、MuleSoft またはカスタムインテグレーションレイヤーが必要です。

チームは複雑な ETL パイプラインを実行して Snowflake 分析データを CRM Analytics データセットにアップロードしました。パイプラインは低速で壊れやすく、継続的なエンジニアリングメンテナンスが必要でした。

CRM Analytics SyncIn は、選定された Snowflake 集計ビューを Salesforce カスタムオブジェクトに直接同期するように設定されました。チームは、CRM Analytics データセットではなく、それらのオブジェクトから参照するように CRM Analytics ダッシュボードを再設定しました。その結果、2 つの ETL パイプラインが不要になり、同期時間が 4 時間から 30 分に短縮され、システム管理者はエンジニアリングチケットを上げることなく同期設定を変更できるようになりました。

データチームは、Snowflake の運用データストアで物理削除された Salesforce レコードを追跡する必要がありました。従来のアプローチでは、スプリットジョブと複雑な ID 調整ロジックが必要で、実行に数時間かかり、スキーマの変更も脆弱でした。

チームは、CDC と物理削除追跡を有効にして CRM Analytics SyncOut を設定しました。削除されたレコードは、Snowflake 消費テーブルで自動的に DEL_FLAG = ‘Y’ のフラグが付けられるようになりました。下流の分析クエリでは、WHERE DEL_FLAG = ‘N’ が適用され、有効なレコードのみが表示されます。調整ロジックは完全に排除され、同期時間は8時間から15分のインクリメンタル実行にまで短縮されました。

買収中、買収側企業は、固定タイムライン内で組織間レポートと規制コンプライアンスを目的として、6つの大規模 Salesforce オブジェクトを Snowflake に同期しました。

チームは、CDC ベースの増分同期を使用して 6 つのオブジェクトすべてに CRM Analytics SyncOut を設定しました。インテグレーション期間全体でスキーマの変更とレコード件数を追跡したメタデータテーブルを監査します。カスタムコードは作成されていません。データの更新間隔が毎日から 15 分に改善され、監査メタデータテーブルによってコンプライアンスレポートに必要なトレーサビリティが提供されます。

同期ジョブは、組織の API 予算を共有します。大規模なオブジェクトに対して多数の高頻度同期ジョブを実行している組織では、24 時間あたり 15,000 件の API コールの制限を使い果たすリスクがあります。すべての同期ジョブのインベントリを作成し、実行あたりの API 消費量を推定し、負荷を分散するためにスケジュールをずらします。変更率が低いオブジェクトから中程度のオブジェクトの場合、CDC ベースの増分モードでは、完全同期と比較して実行ごとの API 消費量を大幅に削減できます。

SyncIn と SyncOut は Snowflake ウェアハウスに対してクエリとデータ読み込みを実行し、計算クレジットを消費します。単純な SELECT クエリの場合、通常は X-Small または Small ウェアハウスで十分です。大規模な SyncOut ロードの場合、Medium または Large が必要になることがあります。倉庫の自動一時停止 (5 分間無操作) と自動再開を設定します。本番同期ジョブ専用のウェアハウスを使用して、コストを分離し、ユーザーのクエリとの競合を回避します。

Salesforce 項目の名前変更、削除、または API 参照名の変更を行うと、対応する SyncOut 項目の対応付けが通知なしで失敗するか、エラーが記録されます。Salesforce メタデータの変更の一環として有効な同期設定を確認することを含む変更管理プロセスを確立します。Snowflake 監査テーブルには、ドリフトイベントが発生したタイミングを特定するのに役立つ変更履歴が表示されます。

SyncOut での物理削除追跡では、Salesforce オブジェクトで CDC を有効にする必要があります。CDC が有効になっていない場合、「Track Hard Deletes」オプションは無効です。特に初期設定時や組織の移行後に、同期設定チェックリストの一部として CDC の有効化を検証します。

最も一般的な失敗クラスは、ログイン情報の有効期限または権限の喪失です。指定ログイン情報は有効なままであり、Snowflake サービスアカウントは倉庫の使用許可とテーブル権限を保持する必要があります。OAuth ベースの設定では、トークンの更新に失敗すると同期ジョブが停止することがあります。Sync Job Monitor ダッシュボードで認証エラーパターンを監視し、ジョブの失敗に関する Chatter またはメール通知を設定します。

SyncIn では、Salesforce 外部 ID 項目が更新/挿入キーとして使用されます。ソース Snowflake ビューのキー項目の値が重複している場合、影響を受けるレコードの更新/挿入は失敗します。同期設定に達する前に Snowflake ビューレイヤーのキー項目に一意性を適用します。

同期ジョブが失敗すると、プラットフォームは同期ジョブ監視でレコードごとに詳細なエラーメッセージを記録します。一般的な障害シナリオとその解決策:

  • 認証失敗: 指定ログイン情報と Snowflake アカウントの有効期限を確認してください。トークンの更新に失敗した場合は、OAuth を再認証します。
  • 項目マッピングエラー: Snowflake 列と Salesforce 項目間の種別の互換性を確認してください。実行ユーザーの項目レベルセキュリティを確認します。
  • ガバナ制限を超えました。同期頻度を減らすか、増分 CDC モードに移行して API 消費を分散します。
  • Snowflake ウェアハウスの一時停止： ウェアハウスで自動再開を設定するか、次回のスケジュール済み同期の前に手動で再開をトリガーします。
  • 物理削除トラッキングが機能しない： オブジェクトで CDC が有効になっており、同期設定で「物理削除をトラッキング」フラグが設定されていることを確認します。

CRM Analytics データ同期は、Salesforce の適切に設計されたフレームワークの複数の柱に対応しています。

  • 信頼性 (耐障害性): プラットフォームは、実行、再試行ロジック、部分的な障害の処理を自動的に管理します。失敗したレコードは、同期ジョブモニターに個別に記録されます。失敗後にレコード件数の照合を行い一貫性を確認し、失敗通知を追加し、同期ジョブモニターでエラーパターンの再発を監視します。CDC ベースの増分同期では、範囲内のデータウィンドウを制限することで、失敗した実行のブラスト半径を減らします。
  • **Trust:**ログイン情報モデル(指定ログイン情報、外部ログイン情報、認証プロバイダー)は、暗号化ストレージ、トークンの自動更新、一元管理を適用します。Snowflake 側の最小権限アクセス権により、侵害されたログイン情報の爆発半径が制限されます。同期時に項目レベルセキュリティが適用されます。ユーザーは、アクセス権のない項目を同期できません。
  • リソースとコストの最適化: 増分 CDC モードは、パフォーマンスを最適化するための主レバーです。完全同期と比較して、API 消費、同期期間、Snowflake の計算コストが削減されます。Snowflake ビューの事前絞り込みにより、転送中のデータボリュームがさらに削減されます。ウェアハウスの自動サスペンドにより、アイドル状態のコンピュート費用を回避します。
  • Operational Excellence: 宣言型構成モデルでは、同期ジョブはコードではなくメタデータで定義されます。これにより、エンジニアリングの関与なしで監査可能、再現可能、管理可能になります。組み込みのモニタリングダッシュボードでは、カスタムログ記録インフラストラクチャを使用せずに完全な可観測性が提供されます。
  • 信頼性 (スケーラビリティ): プラットフォームでチャンク、ページネーション、Bulk API バッチが自動的に処理されます。レコードボリュームが非常に多いオブジェクトでは、インクリメンタルな CDC モードとオフピークスケジューリングが、ガバナ制限制約内でスループットを維持するための主なアーキテクチャ上の手段となります。

このチェックリストでは、同期設定をセットアップおよび検証するための最小限の手順について説明します。

事前設定チェックリスト：

  • SyncOut 増分モード ([設定] → [変更データキャプチャ]) で使用するすべての Salesforce オブジェクトで [変更データキャプチャ] を有効にします。
  • 最小限の権限を持つ専用の Snowflake サービスアカウントを作成し、必要なテーブル権限と倉庫権限のみを付与します。
  • OAuth 認証を使用している場合は、Snowflake セキュリティインテグレーションを作成します。
  • SyncIn が更新/挿入キーとして使用する各 Salesforce オブジェクトの [外部 ID] 項目を特定し、ソースデータの一意性を確認します。

接続性:

  • Salesforce で認証プロバイダーを作成します ([設定] → [認証プロバイダー])。
  • 外部ログイン情報を作成し、認証プロバイダーにリンクします ([設定] → [指定ログイン情報] → [外部ログイン情報])。
  • 指定ログイン情報を作成し、外部認証情報にリンクします（[設定] → [指定ログイン情報]）。
  • 関連する Salesforce プロファイルへの指定ログイン情報アクセス権を付与します。

SyncOut 設定:

  • Snowflake 接続を作成します ([設定] → [Analytics Studio] → [データマネージャー] → [接続] → [Snowflake 接続])。
  • SyncOut 設定の作成: ソースオブジェクト、対象テーブル、同期モード、項目の対応付け、CDC、物理削除追跡、スケジュール。
  • 日次同期から開始し、頻度を上げる前にデータの品質とパフォーマンスを検証します。

SyncIn構成:

  • 外部データソースを作成します ([設定] → [Analytics Studio] → [データマネージャー] → [接続] → [Snowflake 接続])。
  • [SyncIn 設定を作成]: ソースビュー、対象オブジェクト、外部 ID 項目、項目の対応付け、スケジュール。
  • 未加工のテーブルではなく Snowflake ビューから同期します。

検証:

  • 最初の実行後に [同期ジョブ監視] を確認します ([設定] → [Analytics Studio] → [データマネージャー] → [同期ジョブ監視])。
  • Snowflake 監査テーブルを照会して、同期メタデータが書き込まれたことを確認します。
  • DEL_FLAG 列が存在し、入力されていることを確認して、物理削除フラグを検証します。
  • 取得元と取得先のレコード件数を比較します。
  • Chatter またはメールでの失敗通知を設定します。

このパターンは、スケジュール済みバッチ同期が遅延要件を満たし、双方向のデータフローが必要で、インテグレーション操作へのエンジニアリングの依存を減らすことが優先される場合に使用します。

このガイドの Snowflake の作業例では、ライフサイクル全体 (接続の設定、設定、実行フロー、検証) を示しています。サポートされている外部データプラットフォームにも同じ原則が適用されます。

15 分未満の遅延、複雑な変換、または複数組織のシナリオが対象である場合、補完的または代替的なアプローチとしてプラットフォームイベント、ストリーミング API、または MuleSoft を評価します。

Yugandhar Boraは、Salesforceのソフトウェアエンジニアリングアーキテクトで、Data & Intelligence Applications プラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞った Enterprise Architecture Review Board (EARB) イニシアチブを主導しながら、自動化されたプラットフォームプロビジョニングソリューションに貢献しています。