tyoshikawa1106のブログ

- Force.com Developer Blog -

SFDC:リードソース項目とレコードタイプの選択リスト値の設定について

標準オブジェクトの『取引先』『取引先責任者』『リード』『商談』には、標準項目としてリードソース項目が用意されています。これは少し特殊な項目となっています。

[取引先] 取引先ソース (AccountSource)

f:id:tyoshikawa1106:20160329104624p:plain

[取引先責任者] リードソース (LeadSource)

f:id:tyoshikawa1106:20160329104846p:plain

[リード] リードソース (LeadSource)

f:id:tyoshikawa1106:20160329105022p:plain

[商談] リードソース (LeadSource)

f:id:tyoshikawa1106:20160329104912p:plain


これらの選択リストは共通の値が適用されます。なので次のようにリスト値を変更すると・・・
f:id:tyoshikawa1106:20160329105136p:plain


他オブジェクトのリスト値も自動で変更されます。
f:id:tyoshikawa1106:20160329105320p:plain

f:id:tyoshikawa1106:20160329105408p:plain


項目のリスト値は共通ですが、レコードの値は独立しています。そのため取引先レコードのリードソースの値が取引先責任者レコードのレコードソースの値に自動でセットされたりというようなことはありません。

リードソースとレコードタイプ

レコードタイプにはそれぞれのレコードタイプ毎に使用できる選択リスト値を設定できます。ここについても確認してみました。まずそれぞれのオブジェクトに新しいレコードタイプを追加する場合は特に意識することはありません。
f:id:tyoshikawa1106:20160329110124p:plain


注意が必要なのはレコードタイプ設定後に、リードソース項目に新しいリスト値を追加した場合です。この対応を行う場合はどのレコードタイプで利用できるようにするか手動で選択する必要があります。
f:id:tyoshikawa1106:20160329111535p:plain

既存レコードのリスト値とレコードタイプのリスト値制限

レコードタイプで選択リストを制限できますが、作成済みのレコードがレコードタイプ変更時に既にセットされている値はどうなるか確認してみました。
f:id:tyoshikawa1106:20160329111024p:plain


既に利用されている値はそのまま利用できるようになっています。
f:id:tyoshikawa1106:20160329111141p:plain


一度値を変更すると、指定不可の値は利用できなくなります。
f:id:tyoshikawa1106:20160329111238p:plain


レコードタイプでリスト値制限を追加しても既存レコードの値はそのままになることは覚えておくといいと思います。

レコードタイプ設定とリスト値の削除

リードソース項目のリスト値を削除する場合の動作についてです。このように既に利用されているリスト値を削除してみます。
f:id:tyoshikawa1106:20160329112223p:plain


共通のリスト値なので一つのオブジェクトで削除されれば他もまとめて反映されます。
f:id:tyoshikawa1106:20160329112322p:plain


選択リストのリスト値削除を行う場合まとめて別の値に置換できる仕組みが用意されています。
f:id:tyoshikawa1106:20160329112523p:plain


これで取引先や商談などのリードソース項目の値をまとめて置換できました。
f:id:tyoshikawa1106:20160329112717p:plain


この置換処理はレコードタイプのリスト値制限に関係なく実行できます。置換後の値で「なし」を選択した場合は削除されたりせずに元の値のまま残すことができるみたいです。

おまけ

選択リスト値削除による置換処理ですが、非同期で実行され実行後に完了メールが届きます。
f:id:tyoshikawa1106:20160329114351p:plain


実行状況は設定のバックグラウンドジョブで確認できます。
f:id:tyoshikawa1106:20160329114616p:plain


たしか...の話ですがこの置換処理によるApexトリガの実行はありませんでした。