【初心者向け】Salesforceの主従関係･参照関係とは？違いや使い分けを解説

目次

はじめに

Salesforceのオブジェクトリレーションとは？

「主従関係」と「参照関係」の違いは？

どんな時にどちらを使うのがベスト？

リレーションを作成する手順

応用編：多対多を作りたい時はどうする？

まとめ

   はじめに

たとえば皆さんが「顧客リスト」と「商談」や「見積」「契約」などをエクセルのシートでそれぞれ管理し業務するところを想像してみてください。

最初のうちはエクセルでも十分かもしれませんが、顧客が増えるほどデータが膨大になり管理が大変ですよね。A社との商談、見積もり、契約を全部見ようとすると、シートを何度も行ったり来たりする必要があります。

一方　Salesforceであれば、顧客に紐づく商談・見積・契約等のデータをまとめて確認することができます。これは、Salesforceのオブジェクト同士が「リレーション」という機能で紐づけられているからです。

ただ、このオブジェクト同士の紐づけという概念は実際にイメージすることが難しく、「実はよくわかっていない…」という方も多いのではないでしょうか。

この記事では、リレーションの概要と、リレーションの中でも特に重要な2種類、「主従関係」と「参照関係」の機能や使い分けをわかりやすく解説します。

   Salesforceのオブジェクトリレーションとは？

Salesforceのオブジェクトリレーションとは、異なるオブジェクト同士をつなげるための仕組みのことです。実際にリレーションを使うことでどのような見え方になるのか、取引先オブジェクト（親）と商談オブジェクト（子）を例に見てみましょう。

・取引先のレコードページから、その取引先に紐づく商談をまとめて確認できます。

これができるのは、取引先と商談の間にリレーションがあるためです。

・一方、商談のレコードページから、その商談が紐づいている取引先も確認できます。

こうした「相互に関連するデータをつなぐ」仕組みが、リレーションの基本イメージです。

今回の例だと、1件の取引先に対して複数の商談が紐づく形（つまり1対複数の構造）になります。

このような時、取引先オブジェクト側を「親」と呼び、商談オブジェクト側を「子」と呼ぶことになります。

アップビルダーが300名以上在籍！

テラスカイ・テクノロジーズのエンジニア派遣の資料ダウンロードはこちら

→https://www.terrasky-tech.co.jp/document/about

   「主従関係」と「参照関係」の違いは？

Salesforceで利用できるオブジェクトリレーションには、いくつかの種類があります。

ここからは、最も頻繁に使われる「主従関係」と「参照関係」について見ていきましょう。

前提として、下記2つのカスタムオブジェクトを例にします。

この「イベントオブジェクト × イベント申込情報オブジェクト」を、主従関係として扱う場合と参照関係として扱う場合で、どのように違いが出るのかを見ていきましょう。

■主従関係として扱う場合

主従関係は、親レコードと子レコードが「強く結びつくリレーション」とイメージすると特徴を覚えやすいです。主な特徴は以下のとおりです。

特徴①：親レコードが削除されると、子レコードも自動的に削除される

→たとえばイベントのレコードを削除したら、そのイベントに紐づくイベント申込情報のレコードも同時に削除されます。

特徴②：権限や共有設定が親に連動する

→子の閲覧権限や編集権限は、原則として親レコード側の設定に左右されます。

特徴③：積み上げ集計項目がが使える

→親のレコード側で、紐づく子レコード件数を合計するなどの集計項目が利用可能です。

→たとえばイベントごとに参加者の合計人数を自動的に算出することもできます。

特徴④：子レコードに「所有者」項目が存在しない

→主従関係では子オブジェクト側に「所有者」項目がなく、実質親レコードと同じ所有者ということになります。

■参照関係として扱う場合

参照関係は、「親と子の結びつきがゆるやかな」リレーションとイメージすると特徴を覚えやすいです。主な特徴は以下のとおりです。

特徴①：親レコードが削除されても子レコードは残せる

→過去のイベントが削除されても、申込情報のレコードを履歴として残しておきたいときに便利です。

特徴②：権限や共有設定は親とは独立

→子オブジェクトのレコードを個別に権限管理したい場合に役立ちます。

特徴③：積み上げ集計項目が使えない

→積み上げ集計項目を使うことはできません。よって、イベントレコード側で、イベント申込情報の合計数を出すといったことができなくなります。　※ただし、フローなどで開発で補うことが可能です。

■主従関係と参照関係の違いまとめ

※他にも細かい制約や違いがあります。詳細は公式ヘルプを確認してください。

https://help.salesforce.com/s/articleView?id=sf.relationships_considerations.htm&type=5

   どんな時にどちらを使うのがベスト？

ここまで、主従関係と参照関係の特徴や違いをお伝えしてきました。

「違いは分かったけど、実装する際にはどっちを使えばいいんだろう？」と思う方もいることでしょう。

そこで、使い分けの例をいくつかご紹介します。

例①：積み上げ集計項目を利用したい場合

→主従関係であれば特に開発をしなくても積み上げ集計項目を利用できます。ただし、参照関係であっても一定工数をかけてフローなどで代替することが可能です。

例②：アクセス権を親レコードと子レコード間で連動させたい場合

→主従関係の採用が推奨です。参照関係であってもApex等で代替も不可能ではありません。

→逆にアクセスを連動させたくない場合、参照関係を選択することしましょう。主従関係だと必ずアクセス権が連動してしまうためです。

例③：子レコードが存在するには、親レコードを必須としたい場合

→どちらかというと主従関係が推奨ですが、参照関係でも必須設定を適用することはできます。

→一方で、親レコードを任意とするには、参照関係を使いましょう。主従関係では、親レコードが必須となるためです。

例④：親レコード削除時、子レコードも自動的に削除したい場合

→主従関係が推奨ですが、参照関係であっても一定工数をかけてフロー等で代替することが可能です。

→一方で、親削除時に、子レコードを残したい場合は参照関係を採用することがマストです。

例⑤：親子間で所有者を分けたい場合

→参照関係が推奨です。主従関係だと子レコード側に所有者項目は存在しません。

例⑥：あとから親レコードの付け替えをできるようにしたい場合

→どちらかというと参照関係が推奨です。主従関係であっても設定を行えば可能です。

参考：使い分け早見表

今回は1つずつの観点に切り分けて紹介しました。

実際には検討すべき観点が複数あると思いますので、上記を参考に、網羅的に検討して「主従関係」「参照関係」を選択していきましょう。

例：積み上げ集計項目を利用したいが、アクセス権は連動させたくない場合

→参照関係を採用し、積み上げ集計についてはフローで代替する　等

   リレーションを作成する手順

主従関係と参照関係の使い分けをご理解いただいたところで、実際の設定方法を解説します。

ここでは、すでに作成済みのイベントオブジェクト（親）とイベント申込情報オブジェクト（子）に対して、参照関係を設定していきます。

子オブジェクト側に「参照関係項目」を作成することで、両オブジェクト間に「参照関係」のリレーションを張ることができます。

■設定手順

1.オブジェクトマネージャーから、「イベント申込情報（子）」へアクセスし、 [項目とリレーション] から [新規]ボタンを押下します。

2.データ型で「参照関係」を選択します。

3.関連先（親オブジェクトのこと）として「イベント」を選択します。

その後の画面に従って、項目レベルセキュリティや、ページレイアウトの設定を行います。

※一つひとつの手順は割愛します

すべての設定を終えたら、実際に見え方を確認してみましょう。

まず、親となる「イベント」レコードを1件登録し、そのイベントレコードの関連リストを開きます。

「新規」ボタンを押下し、2件ほど「イベント申込情報」レコードを作成します。

すると、このように「1つのイベントに、複数の申込情報が紐づく」状況を作ることができました。

   応用編：多対多を作りたい時はどうする？

これまでの例では、イベント申込情報（=参加者情報）が1つのイベントだけを指すケースを想定していました。

しかし現場では、以下のようないわゆる「多対多」の状況が発生することもよくあります。

たとえば、

・1つのイベントに対して、複数の申込（参加者）が発生し、かつ

・1人の参加者が、複数のイベントに申込を行うケース　など。

この「多対多」を実現するには、「中間オブジェクト」を挟むのが一般的です。たとえば「イベント」と「参加者」という二つの親オブジェクトを用意して、その間に「イベント申込情報」という子オブジェクトを設け、双方のリレーションを結びます。

これによって、「1つのイベントに複数の参加者」「1人の参加者が複数のイベントに参加する」状況を柔軟に表現できます。

作成手順は、上記の方法と基本的には同じです。 （2つの「主従関係項目」を作成するだけです）

参考：オブジェクト間のリレーションイメージ

実際の見え方を確認してみましょう。

あらかじめ、以下のレコードをそれぞれ作成しておきます。

・イベント：セミナー

・参加者情報：山田太郎

その後、以下の通り「イベント申込情報」を新規で作成する際、上記「イベント」と「参加者情報」を紐づけます。

すると…

イベント、参加者情報ともに、関連リストには「イベント申込情報」が複数紐づいていることが確認できました。

これで、達成したかった以下の2つの要件を満たすことができました！　

・1つのイベントに対して、複数の申込（参加者）が発生するケース

・1人の参加者が、複数のイベントに申込を行うケース

   まとめ

いかがでしたでしょうか。こうしたリレーションの設計を最初の段階でよく考えておくと、その後のSalesforceの運用や拡張が格段にスムーズになります。

ぜひ本記事で紹介させていただいた知見を、リレーション設計に活かしてみてください。

また、ここで紹介しきれなかった観点や制限も多くあります。ぜひSalesforceのヘルプを読んでみてください。

この記事を書いた人

M S（Salesforceデベロッパー）

🏅保持資格

・Salesforce 認定 Platform アドミニストレーター

・Salesforce 認定 Platform アプリケーションビルダー

・Salesforce 認定 Platform アドミニストレーター 上級

・Salesforce 認定 Platform デベロッパー

・Salesforce 認定 Sales Cloud コンサルタント

・Salesforce 認定 Experience Cloud コンサルタント

・Salesforce 認定 Marketing Cloud Account Engagement スペシャリスト

・Salesforce 認定 AI アソシエイト

・Salesforce 認定 Agentforce スペシャリスト

・Salesforce 認定 Data Cloud コンサルタント

・Salesforce 認定 JavaScript デベロッパー

・Salesforce 認定 MuleSoft Integration 基礎

・Salesforce 認定 MuleSoft デベロッパー

Salesforce（Sales Cloud、Marketing Cloud Account Engagement）などの保守開発、運用などを担当。人材業界で約4年ほどの経験がある。エンドユーザとの要件定義や開発リーダーなども担当。

アップビルダーが300名以上在籍！

テラスカイ・テクノロジーズのエンジニア派遣の資料ダウンロードはこちら

→https://www.terrasky-tech.co.jp/document/about