最初は削れ、ページレイアウトとレコードタイプ

こー。

こんばんは、場末のSFコンサルタント、こー。です。
先週重たいのを書いたので、今週はごく軽い話を。
軽いので、実は違う話を二つ詰め合わせです。最初の最初にSalesforceを触るときに気を付けてほしいことを二つ申し上げます。


本稿のまとめ

本稿のまとめです。これでわかった人は本稿が不要な人なので読み飛ばしていただいて構いません。ご一緒に頑張りましょう。

  • ページレイアウト

    • 用途がはっきりしない項目はとにかく削った方がいい。

    • 特に標準オブジェクトの標準項目。
      取引先の住所など、二つあるが使い分けられるか？

  • レコードタイプ

    • レコードタイプは、一度作ると後戻りが大変。
      どうしても必要な時以外は作らない。

    • ”どうしても必要な時”は、以下のいずれか

      • プロセスをどうしても分けたい

      • 選択肢をどうしても表示レベルで制限したい

ページレイアウトは、本当に必要な項目以外は削ろう

Salesforceを契約して一番最初に試してみるのは、「項目を作って配置する」ことだと思います。
わかります。楽しいですよね。
あった方がいい項目をどんどん作ってどんどんページレイアウトに配置していくと、”仕事が進んでいる感じ”がして大変気持ちがいいものです。

ですが、出来上がったものはどうでしょう。
あった方がいい項目、というのは、大抵”全員は使わない項目”です。
結果的に、誰が操作するときも「この項目使わないんだけどなー・・・・」という項目がたくさんある画面が出来上がります。

ということで、私がSFの初期導入する際、一個のパターンとしてご案内しているのが、「本当に用途がはっきりしている項目以外は削っときましょう」です。
理想は項目詳細ページを開いた時のスクロールがない状態、です。

具体例を見てみましょう

【払い出したばかりの取引先】

払い出したばかりのdeveloperEditionの取引先ページレイアウト

項目がたくさんあって、いかにも完成したシステムっぽさがあります。いいですね。
でも、以下の項目、メンテナンスできますか？

  • 年間売上
    あったらうれしい。でも、メンテナンスは大変。定期的に洗い替えしないとどんどんデータの鮮度が下がっていく。

  • 会社形態
    相手が上場か非上場か。貴社にとってその情報は必要か？関係あるのか？

  • 住所(納入先)
    請求先と納入先を分けることは貴社にとって必要なことか？片方だけではダメか？

【項目を削った取引先】

ぐっと削った取引先ページレイアウト

不安になるくらい削りました。正直削ってみてかなり不安になっています。が、逆にここまで削ると「全部埋めてください」も現実的ですよね？
特に、右上のボタンもごく最小限まで削ったところがポイントです。

項目の考え方を整理する

私の考えでは、Salesforceの項目はざっくり以下の２分類いずれかに分けられると思っています。そこがはっきりしない項目は大体運用できません。

  1. 分析軸になる情報
    レポートでフィルタしたり、集計するための条件になる項目。
    先の例では、年間売上や会社形態がここにあたると思います。

  2. 業務遂行上必要な情報
    先の例では、住所(納入先)がここにあたると思います。

※　ある程度進んでくると、「システム自動化の都合上、中間で項目を用意する」みたいなものが出てきます。
例えば、「数式が巨大すぎでコンパイルできない場合に、一旦レコードトリガフローで値退避を行う」ケースなどです。ヘルプにも記載のあるよくある運用回避実装と思います。

最初にストレスなく活用するために

特にSalesforce最初期は、現場がSalesforceに懐疑的であることが多いと思います（もしかしたらadminもSalesforceに懐疑的かもしれません）。
なので、なるべく早い段階で

  • ゴミが入っていない＝正しいデータしか入っていない

  • 日々の業務でデータを入れると状態がわかってうれしい

を作らないといけません。

そのための1要素として、「悩む項目は全部削る」をお勧めしたいと思います。
※　この辺りのもう少し掘り下げた話は、【成果を生み出すためのSalesforce運用ガイド】がおすすめです。5章あたりがこの辺りの話と思います。

レコードタイプは代替案がないかをよく考える

素直に考えるとレコードタイプを使うのが自然

初めて触るSalesforceでオブジェクト設定をしていくと、以下のようなシーンに出くわすと思います。

「商談には新規商談とアップセル商談があります。それぞれは別ものとして管理したいです」

このシーンを素直に向き合うと、
「レコードタイプわけましょうか」
と考えがちです。
「レコードタイプを分けたからページレイアウトもわけましょうか」もセットになるのではないでしょうか。

レコードタイプのデメリット

でも待ってください。レコードタイプのデメリットを実感していますか？
さっと上げるだけで、以下のようなデメリットがあります。

  • レコードタイプが混在しているとインライン編集が出来ない。
    リストビューでの一括編集（インライン編集）は、レコードタイプが古材していると実施できません。

  • ページレイアウト割り当てが煩雑。
    ページレイアウトはレコードタイプ別に分けられるようになっています。ということは、「分ける必要がない場合も設定上分けて指定が必要」となります。

  • フローで自動化する際に、レコードID指定が必要。
    レコードID指定が必要、ということで、レコードIDをべた書きする実装、初学者はやりがちです。これは、SandBoxの運用を始めたあたりでいきなり動かなくなるパターンなので、原則避けた方がいいです。

  • いざ削除しようとすると、削除手順が複雑。
    レコードタイプをゼロに戻すのは結構大変です。
    具体的には

    1. プロファイル上、そのレコードタイプをデフォルト指定しているものを解除する。

    2. レコードタイプを無効化する

    3. レコードタイプを削除する
      （この時、既存データで削除するレコードタイプが使われている場合、削除に伴うレコードタイプの置き換え更新が走る）

また、レコードタイプそのものの特性、というより、その運用上の特性ですが、【データ分類に使うような値は、入力規則の条件に組み込みされがち】というのも話をややこしくしています。
意識的にコントロールしないと、「昔作った＆今使ってない取引先レコードタイプを条件にした入力規則のせいで、取引先の一括クレンジングが全く進まない」みたいなことが容易に起こります。

レコードタイプは、”代替策がない場合に使う”で十分

上記のデメリットを考えると、レコードタイプは”代替策がない場合に使う”で十分だと思います。

以下のパターンが”代替策がない場合”に該当するかと思います。

  1. プロセスを分けたい
    例えば、代理店商談と自社商談で商談ステップが全く違う、というケースで、どうしてもプロセスを分けたい場合はレコードタイプの分割が必要になります。

  2. ページレイアウトを明確に分けたい
    例えば、法人顧客の取引先責任者と、個人顧客の取引先責任者で、管理項目が全く違う、という場合、レコードタイプの分割と個別のページレイアウト設定を行うのが選択肢に上がります。
    ※　最近は、動的フォームを使うほうがいいかもしれません。私はまだ動的フォームにやや懐疑的なので、Summer24時点のコメント、ということでご理解いただければ幸いです。

  3. 選択肢項目の抑止管理を徹底したい
    例えば、顧客取引先とパートナー取引先で、ある選択肢項目のプルダウン値を出し分けたい、という場合は、検討の余地があります。
    ※　この場合は、まず分類用の選択肢項目を設定＆それに対する連動選択肢リストの設定を実施してみて、それで回避不能かよく考える方がいいと思います。

結びに

初めてSalesforceを設定＆素直に作るとハマりそうなこと、として、ページレイアウトの項目とレコードタイプ設定について触れてみました。
私も結構長いことこの辺りは無邪気に作っていたような気がします。

無論メリットデメリットはありますので、これが絶対ではないですが、デメリットを知ってから作業する、でも遅くないと思います。

それでは、また。

いいなと思ったら応援しよう！