Salesforce のデータ設計の考え方 (標準オブジェクト編)
年末の振り返りの時期ですが、それと合わせてしょっさんがアーキテクトとして考えてることも振り返り、自分がいつも何を考えているのかちょっと整理してみようと考えました。
先日の記事は、お陰様でアーキテクトネタとしては異例のアクセス数で、みんな困ってるんだなーってイロイロ感じました。なかなかね、弊社の社員がこういったネタを書くことってないでしょうからね。新鮮さもあるかもしれません。英語だと色々あるんだけどね。
さて、せっかくだから、この記事で分類してカテゴリごとに考えてみます。今日のネタは「データ」一つ目です。
標準オブジェクトを理解する
Salesforce をきちんと理解するなら、Fit to Standard を心がけることが不可欠です。となるとデータの観点で考えなければならないことは「標準オブジェクトを理解する」コトです
標準オブジェクトは、Salesforce が業態(Sales Cloud や Service Cloudなど)にあわせて、初期設定されているオブジェクト群のことです。Salesforce がこれまでの多くの知見を生かして初期化したデータモデルで、設計や設定をせずに最初から利用できるデータモデルです。インフラ屋さん的に言えば、DBMS をインストールすると自動的に必要なテーブルの初期構成が完成している状態と考えましょう。
さてそんな便利な標準オブジェクトですが、みなさんが考える以上にたくさんあります。
しかも恐ろしく複雑な構成をしている真似したくない活動オブジェクトなどもあります。
自社のビジネスプロセスに合わせると、使い勝手の悪い標準オブジェクトもあるかもしれません。ただ、それでも標準オブジェクトを利用した方が良いことも多いのは事実。できる限り、標準構成をカスタマイズして利用することを念頭に置きましょう。そして、標準オブジェクトで利用できるオブジェクトと Sales や Service で利用できるオブジェクトを理解し、適切なライセンスを選択できるようにします。これはSalesforce の設計・実装を行うエンジニアの必須事項です。
どのライセンスだと、どのオブジェクトが使えるの… みたいな危惧はあるでしょう。わたしもそういった情報は持っていますが、外部に出して良いものかよく分かっていないので、弊社のAE(営業)へ問い合わせましょう。分かりやすい図がきっと出てきます。
知らんけど。
標準オブジェクトのメリット
そこまで推す標準オブジェクトの価値とは。
まぁ、ここに書いてあるんですけどね。弊社からの営業的なメッセージはこちらを確認ください。きちんとまとまってるとは思う。
標準仕様に合わせていけば、設計や設定にかかる時間は短縮できます。また、Agentforce など Salesforce の AI 機能を始め、最新の機能群は標準オブジェクトを利用することでその恩恵が受けられるように作られています。年3回のアップグレードの恩恵を一番に受けることができるようになっているんですね。
とは言え。最新の機能が使いたいんじゃなくて、安定して自社のプロセスにあったものが使いたい、というケースもあるでしょう。だから、カスタムオブジェクトできちんと設計して利用されていたり。
それがコアコンピタンスで、企業としての価値を高める為の業務であればそれが良いと私も考えます。
でもね。
そこまで業務に色をつける必要性のない業務は山ほどあります。管理系主体のバックオフィス業務ってそこまで差は出ません。汎用化された機能を利用できた方が素早くサービスインできますし、学習効果も高くなる傾向にあります。営業管理やサポート業務を外販するんだ、と言うことでもない限り、Salesforce の標準機能に従ってしまった方が楽だし、自動的に最新の機能が利用できるわけです。
だからこそ、標準のデータ構成を正しく理解して、活用できるようになることが Salesforce の設計者として大事な要素であると考えています。
いいなと思ったら応援しよう！
