背景と適用シナリオ
Salesforce のレポート機能は非常に強力で、リアルタイムのビジネス状況を把握するための不可欠なツールです。商談パイプライン、進行中のケース、キャンペーンの効果など、現在のデータを瞬時に可視化できます。しかし、標準のレポート機能には一つの大きな制約があります。それは、「今この瞬間」のデータしか表示できないという点です。
例えば、以下のような問いに答えたい場合、標準レポートだけでは困難です。
・先週末時点での、営業チーム全体のパイプラインの合計金額はいくらだったか？
・過去6ヶ月間、月ごとのオープンケース数はどのように推移してきたか？
・四半期の初めと終わりで、リードのステータス分布はどのように変化したか？
これらの問いに答えるためには、特定の時点でのデータを「スナップショット」として保存し、時系列で比較分析する必要があります。この課題を解決するために Salesforce が提供している宣言的な（コード不要な）機能が Analytic Snapshots (分析スナップショット) です。
Analytic Snapshots を使用すると、特定のレポートの結果を定期的にカスタムオブジェクトに保存し、データの履歴トレンドを追跡・分析できます。これにより、ビジネスの動向をより深く理解し、将来の予測や戦略立案に役立つインサイトを得ることが可能になります。Salesforce 管理者としてこの機能をマスターすることは、データドリブンな組織文化を醸成する上で非常に重要です。
原理の説明
Analytic Snapshots の仕組みは、3つの主要なコンポーネントの連携に基づいています。このプロセスを理解することで、設定やトラブルシューティングが容易になります。
1. ソースレポート (Source Report)
スナップショットのデータソースとなるレポートです。このレポートは、表形式 (Tabular) またはサマリー形式 (Summary) である必要があります。マトリックス形式や結合形式のレポートはソースとして使用できません。ソースレポートの各列が、後述するターゲットオブジェクトの各項目（フィールド）にマッピングされるデータの元となります。ここで重要なのは、スナップショットが取得するのはレポートの最初の2,000行までという制限です。そのため、レポートには適切な検索条件を設定し、取得したいデータが2,000行以内に収まるように設計する必要があります。
2. ターゲットオブジェクト (Target Object)
ソースレポートから取得したデータを保存するための受け皿となるカスタムオブジェクトです。スナップショットが実行されるたびに、レポートの各行がこのターゲットオブジェクトの新しいレコードとして作成されます。管理者は、ソースレポートの列に対応する項目をこのカスタムオブジェクトに事前に作成しておく必要があります。
例えば、商談レポートのスナップショットを作成する場合、ターゲットオブジェクトには「商談名」「フェーズ」「金額」「完了予定日」などの項目に加え、「スナップショット実行日」のようなカスタム項目を追加することが一般的です。これにより、いつの時点のデータかを明確に識別できます。
3. 項目マッピング (Field Mapping)
Analytic Snapshots の設定の中核をなす部分です。ここでは、ソースレポートのどの列を、ターゲットオブジェクトのどの項目に保存するかを定義します。例えば、「レポートの『Amount』列の値を、ターゲットオブジェクトの『Pipeline_Amount__c』項目に保存する」といった対応付けを行います。
データ型に互換性があることを確認する必要があります。例えば、レポートの数値列をターゲットオブジェクトのテキスト項目にマッピングすることは可能ですが、逆はエラーの原因となる場合があります。
これらのコンポーネントを設定し、実行スケジュール（毎日、毎週、毎月など）を定義すると、指定した日時に Salesforce が自動的にプロセスを実行します。具体的には、Salesforce がソースレポートを実行し、その結果（最大2,000行）を取得し、項目マッピングに基づいてターゲットオブジェクトに新しいレコードを挿入します。このプロセスが繰り返されることで、ターゲットオブジェクトには時系列データが蓄積されていきます。蓄積されたデータは、通常のオブジェクトと同様に、新しいレポートやダッシュボードで分析することができます。
設定手順の例
⚠️ 分析スナップショットは宣言的な機能であり、直接的なコーディングは不要です。そのため、APIやApexコードの例はありません。代わりに、一般的な設定手順の概要を説明します。
ここでは、「毎週月曜日の朝に、オープンされているすべてのケースの状況を記録する」というシナリオを例に手順を解説します。
ステップ1: ターゲットオブジェクトの作成
まず、スナップショットデータを保存するためのカスタムオブジェクトを作成します。
オブジェクト名: Case Snapshot (ケーススナップショット)
API参照名: Case_Snapshot__c
このオブジェクトに、ソースレポートから取得したいデータを格納するための項目を作成します。
- Case Number (ケース番号): データ型 - テキスト
- Status (状況): データ型 - 選択リスト
- Priority (優先度): データ型 - 選択リスト
- Case Owner (ケース所有者): データ型 - 参照(ユーザ)
- Created Date (作成日): データ型 - 日付/時間
ステップ2: ソースレポートの作成
次に、スナップショットの元となるレポートを作成します。
レポートタイプ: ケース
形式: サマリー形式または表形式
検索条件: 「状況」「次の値と一致しない」「Closed」
表示する列: ケース番号、状況、優先度、ケース所有者、作成日など、ターゲットオブジェクトにマッピングしたい項目をすべて含めます。
レポートを「Case Snapshots Source Report」などの分かりやすい名前で、管理者のみがアクセスできるフォルダに保存します。
ステップ3: 分析スナップショットの設定
[設定] から、[クイック検索] ボックスに「分析スナップショット」と入力し、[分析スナップショット] を選択します。
1. [新規分析スナップショット] をクリックします。
2. スナップショット名を入力します (例: Weekly Open Case Snapshot)。
3. 実行ユーザを選択します。このユーザの権限でレポートが実行されます。システム管理者プロファイルを持つ専用のインテグレーションユーザを設定することが推奨されます。
4. ソースレポートとターゲットオブジェクトに、ステップ1と2で作成したものをそれぞれ選択します。
5. [項目対応の編集] 画面で、レポートの列とオブジェクトの項目をマッピングします。例えば、レポートの「ケース番号」列を「Case Number」項目に対応付けます。
6. [保存] をクリックします。
ステップ4: スケジュールの設定
設定を保存すると、スケジュールの設定画面が表示されます。
1. [頻度] を「毎週」に設定します。
2. [曜日] で「月曜日」を選択します。
3. [希望の開始時刻] を業務時間前の早朝（例: 午前5時）に設定します。
4. 開始日と終了日を定義します。
5. エラー発生時の通知先メールアドレスを設定し、[保存] します。
これで設定は完了です。指定したスケジュールでスナップショットが自動実行され、ターゲットオブジェクトにデータが蓄積されていきます。
注意事項
Analytic Snapshots は便利ですが、効果的に利用するためにはいくつかの制限と注意点を理解しておく必要があります。
権限
・実行ユーザ (Running User): スナップショットを実行するユーザは、「レポート実行」「レポートのスケジュール」「分析スナップショットの管理」権限を持っている必要があります。また、ソースレポートが保存されているフォルダへのアクセス権と、ターゲットオブジェクトへの参照、作成、編集権限も必要です。ユーザが将来無効化されるリスクを避けるため、個人のユーザではなく、専用のプロファイルを持つシステムユーザを設定することを強くお勧めします。
API とガバナ制限
・行数制限: 最も重要な制限は、ソースレポートから取得できるデータが最大2,000行であることです。レポートの結果が2,001行以上になる場合、スナップショットの実行は失敗し、エラー通知メールが送信されます。この制限を回避するためには、レポートの検索条件をより厳密にするか、複数のスナップショットに分割するなどの工夫が必要です。
・実行回数: 組織ごとにスケジュールできる分析スナップショットの数には上限があります。上限は Salesforce のエディションによって異なります。
・データストレージ: スナップショットは実行されるたびにターゲットオブジェクトにレコードを作成するため、データストレージを消費します。特に、毎日実行するスナップショットや、一度に多くのレコードを生成するスナップショットは、ストレージ使用量を急速に増加させる可能性があります。定期的にストレージ使用量を確認し、不要になった古いスナップショットデータをアーカイブまたは削除する戦略を検討する必要があります。
エラー処理
スナップショットの実行が失敗した場合（例: 行数制限超過、項目マッピングエラー、実行ユーザの権限不足など）、実行ユーザおよびスケジュール設定時に指定した通知先メールアドレスにエラー通知が送信されます。エラーメッセージには失敗の原因が含まれているため、内容をよく確認して対処してください。定期的に失敗していないか監視することが重要です。
メンテナンス
ソースレポートやターゲットオブジェクトの構成を変更する際には、注意が必要です。例えば、スナップショットで使用されているレポートの列を削除したり、ターゲットオブジェクトの項目のデータ型を変更したりすると、スナップショットは失敗するようになります。変更を行う前には、必ず関連する分析スナップショットへの影響を確認してください。
まとめとベストプラクティス
Analytic Snapshots は、Salesforce 内でコードを書かずにデータの履歴トレンド分析を実現するための、シンプルかつ強力な機能です。営業パイプラインの推移、サービスチームのKPI追跡、その他多くのビジネス指標の時系列分析を可能にします。
この機能を最大限に活用し、安定して運用するためのベストプラクティスを以下にまとめます。
1. 目的を明確にする
何のために、どのデータのトレンドを追跡したいのかを明確に定義します。これにより、必要なレポートとターゲットオブジェクトの設計が容易になります。
2. 命名規則を徹底する
ソースレポート、ターゲットオブジェクト、分析スナップショット自体の名前には、一貫した命名規則を用いましょう。（例: 「[目的] Source Report」「[目的] Snapshot Data」「[目的] Snapshot」など）。これにより、後から他の管理者が設定を見ても、その目的と関連性を容易に理解できます。
3. 専用の実行ユーザを使用する
前述の通り、個人のユーザアカウントではなく、システム管理者権限を持つ専用のインテグレーションユーザを「実行ユーザ」として設定します。これにより、担当者の退職や異動によってスナップショットが停止するリスクを防ぎます。
4. 2,000行の制限を常に意識する
レポートを作成する際は、必ずフィルタを適用してデータ量を制御し、2,000行を超えないように設計します。定期的にレポートを実行し、結果の行数を確認する習慣をつけると良いでしょう。
5. データガバナンスを計画する
ターゲットオブジェクトに蓄積されるデータの保持期間を定め、古いデータを定期的にアーカイブまたは削除するプロセスを検討します。これにより、無制限のデータストレージ消費を防ぎます。
6. 大規模なデータには代替案を検討する
Analytic Snapshots は手軽ですが、制限もあります。非常に大量のデータ（数万行以上）を扱う場合や、より高度なデータ変換・分析が必要な場合は、Tableau (旧 Tableau CRM) や、外部のデータウェアハウスと連携するETLツール（MuleSoftなど）の利用がより適切な選択肢となります。
Salesforce 管理者としてこれらのポイントを念頭に置くことで、Analytic Snapshots を組織のデータ分析能力を向上させるための信頼性の高いツールとして活用できるでしょう。
コメント
コメントを投稿