レコードタイプの落とし穴｜作る前に知っておきたい5つの判断ポイント
「新規商談とアップセル商談を分けて管理したい」「法人顧客と個人顧客でページレイアウトを変えたい」——Salesforceを使っていると、こんな要望が出てくるのは自然なことです。そして多くの管理者が最初に思いつく解決策が「レコードタイプ」ではないでしょうか。
しかし、安易にレコードタイプを作成してしまうと、後から「インライン編集ができない」「管理が複雑になりすぎた」といった問題に直面することがあります。この記事では、レコードタイプを作る前に確認すべき5つの判断ポイントと、見落としがちな落とし穴について解説します。
レコードタイプとは？30秒でおさらい
レコードタイプとは、1つのオブジェクト内でデータを分類し、用途や目的に応じて見せ方や入力項目を切り替えるための機能です。
レコードタイプを使うと、主に3つのことが可能になります。
1つ目はページレイアウトの出し分けです。レコードタイプごとに異なるページレイアウトを割り当てられるため、たとえば「クレーム対応」のケースでは必須項目を多めに、「一般問い合わせ」ではシンプルなフォームを表示する、といった使い分けができます。
2つ目は選択リスト値の制御です。同じ選択リスト項目でも、レコードタイプによって表示する値を変えられます。営業部門には「代理店経由」「直販」を表示し、マーケティング部門には「Web問い合わせ」「展示会」を表示する、といった制御が可能です。
3つ目はビジネスプロセスの分岐です。商談オブジェクトであれば、レコードタイプごとに異なる営業プロセス（フェーズの組み合わせ）を定義できます。
見落としがちなレコードタイプの落とし穴
レコードタイプは便利な機能ですが、導入前に知っておくべきデメリットがあります。これらを理解せずに作成すると、運用開始後に「こんなはずでは」となりかねません。
リストビューのインライン編集ができなくなる
これは最も見落とされがちな制約です。Salesforceのリストビューでは、複数のレコードを一括編集できる「インライン編集」機能があります。しかし、この機能は複数のレコードタイプが混在するリストビューでは使用できません。
実際に試すと「インライン編集は無効になっています。編集するには、1つのレコードタイプで絞り込んでください。」というエラーが表示されます。
日常的にリストビューで一括編集を行っている組織では、レコードタイプを導入することで業務効率が下がる可能性があります。レコードタイプで絞り込む手間が増えるだけでなく、全レコードを横断的に編集したいケースでは対応できなくなります。
入力規則との複雑な絡み合い
レコードタイプを条件に含んだ入力規則を作成すると、後々のメンテナンスが困難になることがあります。たとえば「レコードタイプAの場合は項目Xが必須」という入力規則を作成したとします。その後、レコードタイプAを廃止したくなった場合、入力規則が障害となってデータのクレンジングや移行ができない——という状況が発生しがちです。
入力規則、フロー、プロセスビルダーなど、レコードタイプを参照する設定が増えるほど、変更時の影響範囲が見えにくくなります。
レコードタイプ数の爆発的増加
最も深刻な落とし穴が「掛け算による増加」です。
たとえば、商談オブジェクトで「法人向け」「個人向け」の2つのレコードタイプを作成したとします。その後、「新規商談」「既存顧客からの追加商談」でもレコードタイプを分けたくなった場合、理論上は2×2＝4つのレコードタイプが必要になります。
さらに「自社商談」「代理店経由」という分類も加えたくなると、2×2×2＝8つのレコードタイプになります。レコードタイプが増えれば、それに紐づくページレイアウト、パス設定、入力規則もすべて増加し、管理コストは指数関数的に膨らみます。
フェーズごとにレコードタイプを分けると破綻する
「商談のフェーズごとに表示項目を変えたい」という要望から、フェーズ1つにつき1つのレコードタイプを作成するケースがあります。しかし、これはアンチパターンです。
レコードタイプは本来「データの種類を分類する」ためのものであり、「プロセスの段階」を表現するものではありません。フェーズごとにレコードタイプを分けると、1件の商談が進むたびにレコードタイプを変更する必要が生じ、自動化も複雑になります。
さらにパス機能との相性も悪く、パスはレコードタイプごとに設定が必要なため、フェーズ＝レコードタイプにすると、パスの設定自体が意味をなさなくなります。
作る前に確認！5つの判断ポイント
レコードタイプを作成するかどうかは、以下の5つのポイントで判断することをおすすめします。
ポイント①ビジネスプロセスが根本的に異なるか？
最も重要な判断基準です。たとえば、商談オブジェクトで「自社直販」と「代理店経由」では、営業ステップ（フェーズ）がまったく異なるケースがあります。自社直販では「ヒアリング→提案→見積→交渉→受注」という流れでも、代理店経由では「案件紹介→見積依頼→見積回答→受注報告」のように、プロセス自体が違うことがあります。
このようにビジネスプロセス（フェーズ構成）が根本的に異なる場合は、レコードタイプで分けることに意味があります。逆に、プロセスは同じで「一部の項目が違うだけ」なら、後述する動的フォームで対応できないか検討すべきです。
ポイント②ページレイアウトの項目構成が大きく違うか？
次に確認すべきは、表示項目の違いです。ただし「1〜2項目だけ違う」程度であれば、レコードタイプを分ける必要はありません。
目安として、管理する項目の30%以上が異なる場合にレコードタイプの検討をおすすめします。たとえば、法人顧客と個人顧客で取引先を管理する場合、法人では「従業員数」「資本金」「業種」が必要で、個人では「家族構成」「年齢層」「職業」が必要——というように、項目群がまったく違うケースが該当します。
少数の項目だけ出し分けたい場合は、動的フォームの方が適しています。
ポイント③選択リスト値を厳密に出し分ける必要があるか？
選択リストの値をレコードタイプごとに制限したいケースは確かにあります。しかし、その前に連動選択リストで対応できないか検討してください。
連動選択リストは、ある選択リストの値に応じて、別の選択リストに表示される値を制御する機能です。たとえば「問い合わせ種別」で「製品」を選ぶと「製品名」選択リストには製品一覧が表示され、「サービス」を選ぶとサービス一覧が表示される——といった制御が、レコードタイプなしで実現できます。
連動選択リストでは対応できない複雑なケース、あるいはレコード作成時点から選択肢を限定したいケースでのみ、レコードタイプによる制御を検討しましょう。
ポイント④動的フォームで代替できないか？
2020年のSummer '20リリースで登場した動的フォーム（Dynamic Forms）は、レコードタイプの代替手段として非常に有効です。
動的フォームを使うと、項目やセクションの表示・非表示を条件に応じて制御できます。たとえば「商談フェーズが『見積提出』になったら見積関連の項目を表示する」「種別が『クレーム』の場合のみ対応履歴セクションを表示する」といった制御が、レコードタイプを使わずに実現できます。
動的フォームの大きなメリットは、ページレイアウト数を減らせることです。従来はレコードタイプとプロファイルの組み合わせごとにページレイアウトを用意する必要がありましたが、動的フォームを使えば1つのLightningレコードページで柔軟な表示制御が可能になります。
なお、動的フォームは当初カスタムオブジェクトのみ対応でしたが、現在では取引先、取引先責任者、商談、リード、ケースなど、多くの標準オブジェクトでも利用可能になっています。
ポイント⑤将来の拡張性を考慮しても管理可能か？
最後に、将来を見据えた判断が必要です。現時点で2つのレコードタイプを作成しようとしている場合、「今後、さらに分類軸が増える可能性はないか？」を考えてください。
前述のとおり、分類軸が増えるとレコードタイプ数は掛け算で増加します。2×2×2＝8、2×2×2×2＝16…と、あっという間に管理不能な数になります。
また、管理者が一人しかいない小規模組織では、レコードタイプの管理負荷が業務を圧迫することもあります。設定変更のたびに複数のページレイアウトを修正する必要があり、ミスも起きやすくなります。
迷ったら「作らない」が正解です。レコードタイプは後から追加することは比較的容易ですが、一度作って運用を始めたレコードタイプを統合・削除するのは非常に手間がかかります。
こんなときは使わない方がいい
以下のケースでは、レコードタイプの使用は避けることをおすすめします。
「なんとなく分類したい」だけの場合 「新規顧客と既存顧客を分けて見たい」というニーズは、レコードタイプではなく選択リスト項目で十分対応できます。「顧客区分」という選択リストを作成し、リストビューやレポートで絞り込めばよいのです。
フェーズや状態の変化を表現したい場合 前述のとおり、これはレコードタイプの用途ではありません。選択リスト項目とパス機能、または動的フォームを組み合わせて実現しましょう。
表示/非表示の制御だけが目的の場合 「ある条件のときだけ特定の項目を表示したい」——これは動的フォームの得意分野です。レコードタイプを作る前に、動的フォームで実現できないか検討してください。
動的フォームという選択肢も検討してみよう
レコードタイプを使わずに項目の表示制御を行いたい場合、動的フォームは最有力の選択肢です。
動的フォームでできることを整理すると、項目やセクション単位での表示・非表示の制御、項目の必須・参照のみの動的な切り替え、デバイス（デスクトップ/モバイル）による表示の出し分け、そしてレコード項目の値に基づく条件分岐が可能です。
設定方法は、Lightningアプリケーションビルダーでレコードページを開き、「レコードの詳細」コンポーネントで「アップグレードに関するお問い合わせ」をクリックするだけで、既存のページレイアウトを動的フォームに変換できます。
ただし、動的フォームにも制約があります。ルックアップ項目から新規レコードを作成する際のレイアウトは依然としてページレイアウトが使用されるため、完全にページレイアウトを廃止することはできません。
動的フォームとレコードタイプの使い分けとしては、ビジネスプロセス自体が異なる場合はレコードタイプ、同一プロセス内での項目出し分けは動的フォーム——と覚えておくとよいでしょう。
＜まとめ＞迷ったら「作らない」が正解
レコードタイプは強力な機能ですが、導入には慎重な判断が必要です。作成前に以下の5つのポイントを確認してください。
ビジネスプロセスが根本的に異なるか？ —— フェーズ構成自体が違う場合のみ検討
ページレイアウトの項目構成が大きく違うか？ —— 30%以上の項目が異なる場合に検討
選択リスト値を厳密に出し分ける必要があるか？ —— 連動選択リストで代替できないか確認
動的フォームで代替できないか？ —— 表示制御だけなら動的フォームを優先
将来の拡張性を考慮しても管理可能か？ —— 分類軸の増加リスクを想定
レコードタイプを作成するデメリットとして、インライン編集の制限、入力規則との複雑化、管理コストの増大があることを忘れないでください。
Salesforceは「後から機能を追加する」ことは比較的容易ですが、「一度作った設定を元に戻す」のは困難です。迷ったら作らない——この原則を守ることで、長期的に運用しやすいSalesforce環境を維持できます。
