Salesforceのリレーションシップ構造を理解しよう！成功例と失敗例を交えて解説
目次
はじめに
Salesforceをより良く活用するうえで、リレーションシップ構造を理解することはデータ間の関連性を管理し、業務効率を高めるための重要な要素です。
しかし、あまり馴染みがない方にとっては、この構造を理解することは複雑で難しく感じることもあるでしょう。
本記事では、営業担当者やSalesforceを学び始めた方にとっても、リレーションシップ構造をわかりやすく解説します。
設定や運用の成功例と失敗例も交えているので、より使用するイメージがしやすく、業務に役立つ知識となると思います！
Salesforceのリレーションシップ構造とは
Salesforceのリレーションシップ構造は、データ同士のつながりを管理するための仕組みです。
これを理解することで、データの一貫性を保ちながら、効率的に業務を進めることができます。
ここではリレーションシップ構造の概要、階層構造をわかりやすく解説します。
リレーションシップ構造の概要
リレーションシップ構造とは、あるオブジェクト（関連情報をまとめたデータの箱）と別のオブジェクトの間に関係を設定し、それによってデータを組織的に関連付ける方法です。
たとえば、顧客（アカウント）とその連絡先（コンタクト）を関連付けることで、どの顧客にどの連絡先が対応しているかを一目で把握できるようになります。
画像引用元：salesforce公式ヘルプ 「データモデルオブジェクトの表示」
階層構造とは？
Salesforceでは、リレーションシップ構造が階層的に設定されることが多く、これは組織の階層やビジネスプロセスを反映します。
階層構造では、上位のオブジェクトが下位のオブジェクトを管理する形になります。
例えば、ある大企業のアカウントが親アカウントで、その子会社が子アカウントとなるように、親子関係を設定できます。
このような階層構造を設定することで、組織全体のデータを整理しやすくなり、特定のアカウントに関連するすべてのデータを一元管理できます。
主従関係と参照関係
つぎにSalesforceのリレーションシップ構造のなかで重要な「主従関係（Master-Detail Relationship）」と「参照関係（Lookup Relationship）」について見ていきましょう。
ざっくりお伝えすると、主従関係はデータの依存性が高く、参照関係は柔軟性が高いのが特徴です。
状況に応じてどちらを使うかを選択することが重要です。
ここからは「主従関係」と「参照関係」の2種類のリレーションシップ構造のリレーションシップの仕組みや設定時の注意点、そして制限事項について詳しく解説していきます。
主従関係の特徴と注意点
ここからは主従関係の特徴と注意点について、４つにまとめて行きます。
データの依存性
特徴
これは従オブジェクトに関連するデータの合計や平均などを主オブジェクトに表示させる機能です。例えば、ある顧客のすべての注文金額の合計を顧客レコードに表示することができます。データが変更されるとリアルタイムで集計されるので、親オブジェクトで全体の状況を把握しやすくなります。
注意点
→大規模なデータでは、集計処理に時間がかかることがある点には考慮が必要です。
ロールアップ集計
特徴
従オブジェクトが必ず主オブジェクトに関連付けられている必要があり、従オブジェクトは単独では存在できません。そのため、主レコードが削除されると、主レコードに関連するすべての従レコードも自動的に削除されます。この機能によって関連データの整合性が保つことができます。
注意点
→主レコードが削除されると、主レコードに関連するすべての従レコードも自動的に削除されるため、特に主レコードのデータ削除には慎重さが求められます。
アクセス権の継承
特徴
従オブジェクトは主オブジェクトのアクセス権を継承します。つまり、主オブジェクトに対する権限がないユーザーは、その従オブジェクトにもアクセスできません。この特性により、データの一貫性とセキュリティが確保されます。
注意点
→柔軟なアクセス管理を求める場合は注意が必要です。
従オブジェクトの制限
特徴
一つのオブジェクトに設定できる主従関係は最大2つまでとなっています。また、従オブジェクトは他の主従関係でさらに従オブジェクトになることはできません。つまり、
注意点
→主従関係の階層は深くすることができないため、複雑なデータ構造を持つ場合は設計段階での工夫が求められます。
参照関係の特徴と注意点
つぎに参照関係の特徴と注意点を４つ説明します。
データの独立性
特徴
参照関係においては参照元オブジェクトと参照先オブジェクトが互いに独立して存在できるため、より柔軟なデータ構造を実現できます。たとえば、取引先の担当者が辞めてしまうなどのケースでも、その担当者に関連する取引データを残しておくことができます。
注意点
→データが散在するリスクが考えられます。
データが独立しているため、リンクが強制されず、関連情報が分散して管理が複雑になる可能性があります。
データの参照
特徴
参照関係を使用することで、関連するデータを簡単に参照できます。例えば、取引先責任者レコードから、直接その取引先に関連する案件の詳細を確認することができるので、リンクして確認する手間を省けます。
注意点
→参照先が削除された場合、参照項目が空欄になってしまう可能性があります。
参照関係においては参照しているレコードの削除時には注意が必要です。
アクセス権の独立
特徴
参照関係では、オブジェクト間のアクセス権が独立しています。主従関係とは異なり、参照オブジェクトへのアクセス権は個別に設定できるため、柔軟なセキュリティ管理を行うことが可能です。
注意点
→管理工数が増えてしまうことがあります。
これはオブジェクトごとにアクセス権を個別に設定する必要があることにより、管理が複雑になったり、アクセス権の独立のため、整合性の管理が発生するためです。
参照オブジェクトの制限
特徴
参照関係においては参照元オブジェクトと参照先オブジェクトが互いに独立して存在できるため、より柔軟なデータ構造を実現できます。たとえば、取引先の担当者が辞めてしまうなどのケースでも、その担当者に関連する取引データを残しておくことができます。
注意点
→データが散在するリスクが考えられます。
データが独立しているため、リンクが強制されず、関連情報が分散して管理が複雑になる可能性があります。
主従関係と参照関係 制限と影響
ここまでご紹介したように、Salesforceのリレーションシップ構造には主従関係と参照関係にはそれぞれ制限があり、これらを理解しておくことはとても重要です。ポイントを簡潔にまとめると以下の通りです。
主従関係の制限
主オブジェクトが削除された際に従オブジェクトも削除されるため、誤って重要なデータが削除されるリスクがあります。また、従オブジェクトの数や階層の深さに制限があるため、複雑なデータモデルには不向きな場合があります。
参照関係の制限
参照関係ではデータの独立性が高い分、データの整合性を手動で保つ必要があります。また、必須設定をしていない場合、データの欠損が生じるリスクがあるため、適切なデータ入力が求められます。
とはいえ、どちらもとても便利な機能なので、特徴と注意点を理解して必要に応じて積極的に使っていただければと思います。
成功例とと失敗例
ここからは主従関係と参照関係を実際の業務で利用した際の成功例と失敗例を少し具体的に取り上げていきます！
具体的な業務での利用時のイメージの参考になればと思います。
成功例：リレーションシップ設定の活用
事例1: 顧客規模が大きい企業の顧客管理での活用
背景
ある企業では、顧客とその担当者（コンタクト）との関係を効率的に管理する必要がありました。その企業の事業は、顧客の規模が大きく複数の担当者が存在する体制であったため、関係性が複雑になりやすい状況でした。
リレーションシップ設定
そこで「主従関係」を利用し、顧客（主オブジェクト）と担当者（従オブジェクト）を結びつけることで、どの担当者がどの顧客に紐づいているかを明確にしました。またロールアップ集計を活用し、顧客ごとの取引総額を一目で確認できるように設定しました。
結果
結果として、営業チームは取引機会を見逃すことなく、効率的な営業活動が実現しました。さらに重要な顧客に対するリソース配分が適切に行われるようになり、売上の増加につながりました。
事例2: 顧客サポート情報の管理での活用
背景
ある企業の顧客サポート部門では、多数の顧客サポートチケットを管理しており、顧客と販売履歴の紐づけが課題となっていました。
リレーションシップ設定
そこで参照関係を使用して、各顧客とその販売履歴をリンクさせ、サポートスタッフが迅速に販売状況を把握できるようにしました。さらに設定した参照関係を活用して、過去の販売履歴を容易に検索・参照できるようにしました。
結果
結果としてサポートチームの応答時間が短縮され、顧客満足度が向上し、さらに問題発生時に過去の類似ケースに対する解決策の迅速な提供が可能になり、効率的なサポート体制が確立されました。
失敗例：設定時に陥りがちなミスとその解決策
事例1: データの依存性への考慮不足による重要データの誤削除
背景
ある企業では、販売データと顧客データを管理するために、主従関係を設定しました。ところが、主オブジェクトに設定した顧客データが誤って削除されてしまい、従オブジェクトの販売データも一緒に削除されるという問題が発生しました。
問題点
主従関係の特徴であるデータの依存性への考慮が足りず、重要なデータが削除さてしまうリスクのある設定状況でした。
解決策
そこで設定を主従関係から参照関係に変更し、販売データが独立して管理できるようにしました。こうすることで、顧客データが削除されても、販売データは保持されるようになり、データ損失のリスクが軽減されました。また、データ削除の前に確認するプロセスを追加し、重要データの誤削除を防げるように設定を追加しました。
事例2: 参照オブジェクトの制限の考慮不足によるデータの欠損
背景
別の企業では、参照関係を利用して営業案件と担当者をリンクさせていました。しかし、参照関係を必須設定にしなかったため、一部の案件で担当者情報が欠落してしまいました。
問題点
参照関係の特徴である参照オブジェクトの制限の考慮が足りず、必須設定を行わなかったことで、データの一貫性が損なわれました。
解決策
そこで参照項目の設定を必須に変更し、すべての案件に担当者情報が必ず入力されるようにしました。また、データ入力時のチェック機能を強化し、不完全なデータが登録されないようにすることで、データの完全性を確保できるようにしました。
成功例と失敗例からわかること
事例からもわかりますが、Salesforceのリレーションシップ構造は、適切に設定することで業務の効率化やデータ管理の改善に大きく貢献します。
しかし、設定が不適切だと逆に混乱を招き利用者の業務に支障をきたしてしまうこともあります。
これからリレーションシップ構造を考える際にも、注意点を参考にプラスの特徴を活用してみていただければと思います。
まとめ
今回はSalesforceを利用するうえで、必ず知っておくべきリレーションシップ構造に関して、事例を交えて解説する記事をお届けしました。
Salesforceのリレーションシップ構造への理解、深めていただけたでしょうか？
この構造を理解することで、データ管理の効率化に大きく寄与しますので、是非実践でも活用してみてください。
この記事で紹介した知識の内容を参考に、読者様のSalesforce活用をさらに進めていただければ嬉しいです。
それではまた次回もお楽しみに！
