Salesforce を運用するシステムや IT チームにとって、変化のスピードに追いつくことは常に大きな課題です。幸いなことに、プラットフォームには、発見(ディスカバリー)、影響分析、変更管理を支援する多くの標準ツールが用意されています。この記事ではその中の1つである「schema builder(スキーマ ビルダー)」を見ていきます。この非常に便利な機能について知っておくべきことをまとめました。
Salesforce Schema Builder とは?
スキーマビルダーは、組織(Org)のデータモデルを可視化し、編集するためのシンプルなグラフィカル・インターフェイスです。スキーマビルダーでは、ページを行き来してクリックしなくても、ある Object からすべてのフィールドを取得したり、Object への変更について基本的な影響分析を行ったり、その Object に対するすべての依存関係を表示したりできます。また、フィールドの値や必須フィールドといった詳細の確認に加え、マスター・ディテール関係やルックアップ関係の把握にも役立つ優れたツールです。
スキーマビルダーはどのように動作しますか?
Salesforce のスキーマビルダーでは、Object、フィールド、そしてそれらの間の関係が表示されます。これを使うことで、カスタム領域、Object、関係を追加したり、他の Object やフィールドとどのようにつながっているかを確認しながら、カスタムフィールドを表示したり変更したりできます。
スキーマビルダーを初めて開くと、実質的に作業用の空のキャンバスが表示されます。まずは Elements タブに移動し、表示したい Object(複数可)をクリックして、それをキャンバス上にドラッグします。
Object を Salesforce のスキーマビルダーにドラッグすると、関連するフィールドを確認したり、それらが Salesforce の他の部分とどのようにつながっているかを確認したり、新しい Object を作成したりできます。ここでデータモデルに加えた変更は、すべてリアルタイムで本番(production Org)に反映(デプロイ)されます。
(Salesforce Trailhead には、もう少し詳しいウォークスルーがあるので、確認してみてください こちら。)
Schema Builder を使った影響分析
Salesforce のスキーマビルダーの主なメリットの1つは、シンプルな形のインパクト分析ができる点です。スキーマビルダーを使って Object 上のすべての項目(フィールド)を取得すると、変更を加えた場合に何が影響を受けるのかが把握できます。代わりに、変更をそのまま進めて起こり得る影響を待つ場合は、Salesforce のチームに数時間分の作業負担をかけるだけでなく、大きなストレスも招く可能性があります。
ただし、インパクト分析にスキーマビルダーを使うにはメリットとデメリットの両方があります。ここでは、私たちがそれを気に入っている理由と、どこが物足りないのか(そして代わりに何を使えるのか)を手短に見ていきます。
厳選した関連コンテンツ:
Schema Builder:メリットとデメリット
メリット
スキーマ ビルダーの最大のメリットは、その利用しやすさです。現在、ほとんどの Salesforce Classic および Lightning Orgs で利用できます。「Customize Application」の権限があれば、どのユーザーでも作業できます。
このツールは、Org への変更をリアルタイムに展開するのに役立ち、またユーザーがプラットフォーム上で Objects とフィールドがどのように接続されているかを理解するための基礎を提供します。視覚的なインターフェースとドラッグ&ドロップ機能により、使いやすく、カスタマイズを追加する際にもよりインタラクティブな体験が可能になります。
デメリット
先ほど述べたとおり、schema builder で作成した変更はリアルタイムでデプロイされるため、ツールを使用する際に追加のリスクが生じます。ほんの小さなミスでも、デプロイ時点では把握できない可能性がある下流への影響につながることがあります。
そのリスクを影響分析によって軽減する観点では、schema builder は Salesforce における Objects のつながり方を可視化してくれるものの、全体像は提示してくれません。確認できるのは Objects と、それらが他の Objects とどのようにつながっているかまでです。選択した Object 上に存在する関連フィールドの一覧は提供されますが、接続されたフィールドの依存関係は表示できません。
以下では、選択した Objects「Account」と「Contact」が相互に接続されていることが分かります。しかし、接続されたフィールドの依存関係は表示できません。たとえば、フィールドをクリックしても「Annual Revenue」の接続は表示されません。この問題は、Account オブジェクトを変更すると、あなたの Org の別の部分で使われている「Annual Revenue」など、そのオブジェクト上の別のフィールドが意図せず変更されてしまう可能性があることです。
Netwrix Strongpoint の依存関係ダイアグラム
Netwrix Strongpoint の依存関係ダイアグラムは、一目で影響分析を行える直感的なビジュアルツールで、見た目には Salesforce の schema builder と同様の機能が多く備わっています。オブジェクト(Object)からすべてのフィールドを取得して、それらの間のつながりを表示できますが、それだけではありません。さらに一歩進んで、接続されたフィールド上での接続も示し、Org のデータモデルをより包括的に把握できるようにします。
上と同じように、表示する Account Object を選択し、その後 schema builder で行ったのと同様に「Annual Revenue」をクリックします。Netwrix Strongpoint を使えば、組織(Org)内の Annual Revenue フィールドに紐づくすべての依存関係を確認できるため、さらに安全に変更を行えます。
DRD は本番環境へ変更をプッシュするために設計されているわけではありません(そのために、変更管理の仕組みが一式あります)。ただし、schema builder やその他の Salesforce ツールと組み合わせて使用すると、ホットフィックスの展開、使われていないカスタマイズの非推奨化、またはより包括的な開発作業を行う際のリスクを最小化するうえで非常に役立ちます。
重要な変更を展開したい場合でも、組織(Org)全体のクリーンアップを行う場合でも、Netwrix Strongpoint なら、フィールドを非推奨化(deprecate)したり、ピックリストを変更したり、カスタム Object を修正したときに何が起きるかを事前に確認するためのツールが用意されています。これにより、Salesforce 上のあらゆる動作をリスクなしで実行できます。
この短い解説動画をご覧ください:
共有する
もっと詳しく
著者について
Paul Staz
セールス&ビジネス開発担当 副社長(VP)
セールス&ビジネス開発担当のVPとして、Paul は Netwrix のポートフォリオにおけるインフラストラクチャ製品およびアプリケーション製品の成長を推進することを担っています。主な注力領域は、NetSuite、Salesforce、ネットワーク・インフラストラクチャに関するセキュリティとコンプライアンスです。彼は Go To Market Strategies に情熱を持ち、顧客にとって前向きな成果を生み出すことに意欲的です。以前は、Netwrix に買収される前の Strongpoint にて、セールス&マーケティングのVPとして Go To Market 機能を率いていました。Paul は、カナダ・オンタリオ州ハミルトンの McMaster University で、文学士とMBA(経営学修士)を取得しています。