Salesforce レコードタイプの徹底解説：管理者向けガイド

背景と応用シナリオ

Salesforce 組織の管理者として、私たちの主な責務の一つは、ユーザーが効率的かつ直感的に作業できる環境を構築することです。ビジネスが成長し、プロセスが多様化するにつれて、単一のオブジェクト（例えば「商談」や「ケース」）で複数の異なる業務要件を管理する必要が出てきます。ここで非常に強力なツールとなるのが Record Type (レコードタイプ) です。

Record Type は、単一のオブジェクトに対して、異なるビジネスプロセス、Page Layout (ページレイアウト)、そして Picklist (選択リスト) の値を割り当てることを可能にする機能です。これにより、ユーザーの役割や業務内容に応じて、最適な情報入力画面と選択肢を提供することができます。

具体的な応用シナリオをいくつか見てみましょう。

シナリオ1：商談オブジェクトにおける営業プロセスの分離

ある企業が「新規顧客向け営業」と「既存顧客向けアップセル営業」という2つの主要な営業プロセスを持っているとします。

新規顧客向け営業： 見込み客の発見から始まり、要件定義、提案、交渉、契約といった長いステージをたどります。表示される項目には、競合情報や導入障壁といったフィールドが重要になります。
既存顧客向けアップセル営業： 既存の契約状況から始まり、追加ニーズのヒアリング、追加提案、契約更新といった短いステージで構成されます。現在の利用状況や顧客満足度といったフィールドが重要です。

これらのプロセスを単一のページレイアウトとステージ選択リストで管理しようとすると、ユーザーは不要な項目や選択肢に混乱し、データの入力ミスや報告漏れが発生しやすくなります。Record Type を使用して「新規」と「アップセル」の2種類を作成することで、それぞれに最適化されたページレイアウトとステージ選択リストを割り当て、ユーザーを正しく導くことができます。

シナリオ2：ケースオブジェクトにおけるサポートプロセスの多様化

カスタマーサポート部門が、「技術的な問い合わせ」と「請求に関する問い合わせ」の2種類のサポートを提供しているとします。

技術的な問い合わせ： ステータスには「調査中」「開発部門へエスカレーション」「修正パッチ提供済み」などが含まれます。ページレイアウトには、製品バージョンやエラーメッセージといった技術的なフィールドが必要です。
請求に関する問い合わせ： ステータスには「入金確認中」「請求書再発行」「返金処理中」などが含まれます。ページレイアウトには、請求番号や契約期間といった経理的なフィールドが必要です。

この場合も、「技術サポート」と「請求サポート」という Record Type を作成することで、サポート担当者は問い合わせの種類に応じた適切な画面で、迷うことなく業務を遂行できます。

原理説明

Record Type の仕組みを理解するためには、いくつかの構成要素の関係性を把握することが重要です。

1. ビジネスプロセス (Business Process)

これは主に商談、ケース、リード、ソリューションといった特定の標準オブジェクトに存在する機能で、レコードのライフサイクル（フェーズや状況の遷移）を定義します。例えば、商談の「セールスプロセス」やケースの「サポートプロセス」がこれにあたります。Record Type を作成する際には、まずどのビジネスプロセスを使用するかを選択します。これにより、その Record Type で利用可能な選択リスト値（例：商談のフェーズ）が決定されます。

2. ページレイアウト (Page Layout)

ページレイアウトは、レコード詳細ページに表示される項目、セクション、関連リスト、ボタンなどを制御します。Record Type の真価は、このページレイアウトと密接に連携することで発揮されます。

設定は、Profile (プロファイル) または Permission Set (権限セット) を通じて行われます。具体的には、「このプロファイルのユーザーが、この Record Type のレコードを閲覧・編集する際には、このページレイアウトを表示する」という割り当てを行います。これにより、同じオブジェクトのレコードであっても、Record Type によって全く異なるユーザーインターフェースを提供できます。

3. 選択リスト値 (Picklist Values)

Record Type は、オブジェクトのマスター選択リストの中から、その Record Type で利用可能な値を個別に指定する機能を提供します。例えば、商談の「フェーズ」選択リストに10個の値がマスターとして登録されていても、「新規」Record Type ではそのうちの7個だけを、「アップセル」Record Type では別の5個だけを利用可能にする、といった制御が可能です。これにより、ユーザーは現在の業務プロセスに関係のない選択肢を見る必要がなくなり、データの一貫性が向上します。

示例コード

Salesforce 管理者として、直接 Apex コードを書く機会は少ないかもしれません。しかし、開発者と協力したり、Flow やプロセスビルダーの裏側で何が起こっているかを理解したりするために、Record Type がコード上でどのように扱われるかを知っておくことは非常に有益です。

特に重要なのは、特定の Record Type の ID を取得する方法です。レコードを作成または更新する際、Apex や API では Record Type の名前ではなく、一意の ID を使用する必要があります。

以下は、Salesforce の公式ドキュメントで推奨されている、Apex を使用して取引先 (Account) オブジェクトの 'Customer' という名前の Record Type ID を取得するコード例です。

// Schema クラスを使用して、特定の sObject Type (この場合は Account) の
// レコードタイプ情報を取得します。
// getRecordTypeInfosByName() メソッドは、レコードタイプ名をキー、
// RecordTypeInfo オブジェクトを値とする Map を返します。
Map<String, Schema.RecordTypeInfo> recordTypeInfo = Schema.SObjectType.Account.getRecordTypeInfosByName();

// Map から 'Customer' という名前のレコードタイプに対応する ID を取得します。
// この ID は 18 桁の英数字です。
Id customerRecordTypeId = recordTypeInfo.get('Customer').getRecordTypeId();

// 取得した ID を使用して、新しい取引先レコードを作成します。
// RecordTypeId 項目に ID を設定することで、このレコードが 'Customer' レコードタイプとして
// 作成されることを保証します。
Account newAccount = new Account(
    Name = 'Test Customer Account',
    RecordTypeId = customerRecordTypeId
);

// DML (Data Manipulation Language) 操作を実行して、データベースにレコードを挿入します。
insert newAccount;

// デバッグログに作成されたレコードの ID とレコードタイプ ID を出力して確認します。
System.debug('Created new Account with ID: ' + newAccount.Id);
System.debug('Assigned Record Type ID: ' + newAccount.RecordTypeId);

また、SOQL クエリを使用して Record Type の情報を直接取得することも一般的です。これは、特定のオブジェクトに存在するすべての Record Type を動的に扱いたい場合に便利です。

// RecordType オブジェクトから、SObjectType が 'Account' のレコードを問い合わせます。
// SObjectType は、そのレコードタイプがどのオブジェクトに属しているかを示す API 参照名です。
List<RecordType> accountRecordTypes = [
    SELECT Id, Name, DeveloperName 
    FROM RecordType 
    WHERE SObjectType = 'Account' AND IsActive = true
];

// ループ処理で取得した各レコードタイプの情報をデバッグログに出力します。
for (RecordType rt : accountRecordTypes) {
    System.debug('Record Type Name: ' + rt.Name + ', ID: ' + rt.Id);
}

これらのコードスニペットは、管理者としても知っておくべき Record Type の裏側の仕組みを理解する助けとなります。

注意事項

Record Type は強力な機能ですが、無計画に使用すると組織の複雑性を増大させる原因にもなります。導入および運用にあたっては、以下の点に注意が必要です。

1. 権限と割り当て

作成・編集権限： Record Type を作成・編集するには、「アプリケーションのカスタマイズ」権限が必要です。
ユーザーへの割り当て： ユーザーが特定の Record Type を使用できるようにするには、そのユーザーのプロファイルまたは権限セットで Record Type を有効にする必要があります。割り当てられていない Record Type は、レコード作成時の選択肢に表示されません。
デフォルトの Record Type： プロファイルまたは権限セットごとに、デフォルトの Record Type を設定できます。これにより、ユーザーがレコード作成時に特定のタイプを毎回選択する手間を省けます。

2. データ移行と API 連携

データローダーや外部システム連携でレコードを作成・更新する際には、RecordTypeId 項目に正しい 18 桁の ID を指定する必要があります。Record Type 名では認識されません。環境（Sandbox と本番）によって Record Type ID は異なるため、ハードコーディングは避け、上記コード例のように動的に取得する設計が推奨されます。

3. 乱用による複雑化

ページレイアウトのわずかな違い（例：数項目の表示/非表示）のためだけに新しい Record Type を作成するのは避けるべきです。このような要件には、Dynamic Forms (動的フォーム) のような、より新しい柔軟な機能が適している場合があります。Record Type を作成する基準は、「明確に異なるビジネスプロセスが存在するかどうか」であるべきです。

4. 削除と変更の影響

Record Type を削除する前には、その Record Type を使用しているすべてのレコードを、別の Record Type に移行する必要があります。これは大規模なデータ修正作業となる可能性があるため、慎重な計画が必要です。また、ビジネスプロセスや選択リスト値を変更すると、既存のレポートやオートメーション（Flow、Apex Trigger など）に影響が及ぶ可能性があるため、十分な影響調査とテストが不可欠です。

まとめとベストプラクティス

Record Type は、多様なビジネス要件を単一の Salesforce オブジェクト内でエレガントに管理するための、管理者にとって不可欠なツールです。ユーザーごとに最適化された画面とプロセスを提供することで、生産性の向上、データ品質の改善、そしてユーザー満足度の向上に大きく貢献します。

最後に、Record Type を効果的に活用するためのベストプラクティスをまとめます。

ビジネスプロセスを起点とする： テクノロジーありきではなく、まず解決したいビジネス上の課題や分離したいプロセスを明確に定義します。なぜ Record Type が必要なのかを説明できるようにしましょう。
明確な命名規則を設ける： ユーザーと管理者の両方が理解しやすい、一貫性のある命名規則（例：「商談 - 新規事業」「商談 - パートナー経由」）を採用します。DeveloperName も同様に分かりやすく設定します。
設定内容を文書化する： 各 Record Type がどのビジネスプロセスに対応し、どのページレイアウトと選択リスト値のセットを使用しているかを文書として残します。これは将来のメンテナンスや引き継ぎの際に非常に役立ちます。
権限セットを活用する： プロファイルでの一括割り当てよりも、特定のユーザーグループに特定の Record Type へのアクセス権を付与する場合には、権限セットを使用する方が柔軟かつ管理が容易です。
定期的な棚卸しを行う： ビジネスの変化に伴い、不要になった Record Type が存在する可能性があります。半期に一度など、定期的にすべての Record Type を見直し、その存在意義を確認する習慣をつけましょう。
代替案を常に検討する： Record Type が唯一の解決策ではないことを念頭に置き、Dynamic Forms, Validation Rules, 異なるアプリでの出し分けなど、よりシンプルで適切な解決策がないかを常に検討してください。

これらの原則に従うことで、Salesforce 管理者は Record Type の能力を最大限に引き出し、スケーラブルで保守性の高い、ユーザーフレンドリーな組織を構築することができるでしょう。

にゃんこのSalesforce日記

このブログを検索