テリトリー管理のベストプラクティス

テリトリー階層のベストプラクティス

テリトリー管理を使用してロール階層の営業ブランチを簡略化する

テリトリー階層をモデル化するとき、テリトリー管理で自動的に提供されるアクセス権はロール階層に積み上げられることに注意してください。ロール階層の営業ブランチのテリトリー構造を複製しようとすることは不要であり、冗長です。 

代わりに、ロール階層を使用して、管理リレーション、レポートの積み上げ集計、承認、その他の階層的に構造化されたワークフローを設定します。こうした目的のロールのみが含まれるようにロール階層の営業ブランチを簡略化します。次に、テリトリー管理を使用して、ユーザのテリトリー割り当てに基づいて取引先と商談へのアクセス権を拡張します。

売上予測マネージャのいるテリトリーを追加する

元のテリトリー管理とカスタマイザブル売上予測に適用されます。エンタープライズテリトリー管理のテリトリー売上予測とコラボレーション売上予測についての詳細は、Trailhead を参照してください。

Salesforce で売上予測を行う場合、積み上げ要件にアクセスできる売上予測マネージャのいるテリトリーのみをテリトリー階層に追加します。Salesforce で売上予測マネージャのいないテリトリーの売上予測を行うと、そのテリトリーとすべての下位テリトリーは売上予測から除外されます。親ノードに売上予測マネージャが必要なくても、代理の売上予測マネージャを追加して、売上予測が親ノードに積み上げられるようにする必要があります。

継承された取引先割り当てルールを追加する

親テリトリーをテリトリー階層に追加する場合、継承された取引先割り当てルールをそれらのテリトリーに追加することもお勧めします。この方法に従うと、ルールエンジンでテリトリー階層のブランチ全体を評価する必要がなくなり、全体的な共有パフォーマンスが向上します。Salesforce ヘルプの「取引先割り当てルールの管理」を参照してください。

下位から親を再設定する

テリトリー階層を変更するときには、同じテリトリーのアクセス権を再適用する必要がないように、テリトリーの各ノードの親を下位から上位へと再設定します。

詳細なロックの有効化を検討する

特定のテリトリー階層関連の操作には排他的管理ロックが必要です。これにより一時的に組織内のシステム管理者が管理作業を実行できなくなったり、ポータルユーザのプロビジョニングやポータルアカウント所有権の変更など、一部のエンドユーザグループメンバーシップ操作に影響が出たりする可能性があります。

場合によっては、詳細なロックを有効化することでロック操作のパフォーマンスを改善することもできます。詳細なロックでは操作を分析し、テーブルの変更部分のみのロックを試みます。これにより、他のユーザに影響を与えるロックの量を減らすことができます。次の操作は、テーブル全体 (グループ) がロックされるため、詳細なロックによる効果が見込めます。

• テリトリー間でユーザを追加、削除、または移動する

• テリトリーの親を再設定する

• テリトリー内にユーザがいても階層内のテリトリーを作成または削除する

• 売上予測マネージャを追加または削除する

次のタスクのパフォーマンスは、詳細なロックでは改善されません。これらのタスクでは、すでに行レベルのロックを行っているか、ロックが必要ないためです。

• アクセスレベルを変更する

• 取引先への手動割り当てを行う

• ルールを追加、削除、または更新する

• 取引先割り当てをプレビューする

• テリトリーに対してオブジェクトの割り当てや削除を行う

詳細なロックについて詳しくは、「企業の規模に応じたレコードアクセス権の作成」を参照してください。

外部の一元化された情報源と統合する

すでにテリトリーを管理する既存のシステムがあり、それを一元化された情報源 (SSOT) とみなしている場合や、複雑で大規模なテリトリーのセットがあり、それが複数の組織にまたがっている場合があるかもしれません。こうした場合には、外部 SSOT と Salesforce テリトリー管理を統合することを検討してみてください。この統合を容易にするために、テリトリーに SSOT への外部 ID となるカスタム項目を作成できます。

テリトリー階層と外部の SSOT を統合すると、その SSOT から階層をコピーし、それを使用してテリトリーを管理できます。通常、この種のカスタマイズはパフォーマンスへの影響が少なく、コピーした階層は常に外部の SSOT と同期されます。
 

テリトリー割り当てのベストプラクティス

数値項目を使用する

割り当てルールの検索条件ロジックを定義するときは、数値条件をテキスト条件として評価しないでください。項目のデータが数値の場合、必ずその項目が数値項目として定義されるようにします。数値項目をテキスト項目として定義すると評価のパフォーマンスが低下します。Salesforce ヘルプの「カスタム項目のデータ型の変更」を参照してください。

文字列項目に対する条件を定義する代わりに、数値項目に対する条件を定義することを検討してください。文字列項目に対する演算子では大文字と小文字が区別されず、そのことがパフォーマンスに影響する可能性があります。

ピークパフォーマンスを考慮して設計する

• 可能な場合は常に、継承された条件を使用して、取引先の割り当て時にテリトリー階層のブランチ全体に適用しなくてすむようにします。

• 標準の取引先割り当てルールに共有要件を満たすだけの柔軟性がない場合、数式項目に対する割り当てルールを使用することを検討してください。

• ​直接のルールや継承されたルールをできるだけ制限して、ピークパフォーマンスを得られるようにします。

条件項目の代替アプローチを検討する

• 条件エントリの数がビジネス要件を満たさない場合は、数式項目を使用して、取引先の複数のデータ項目を組み合わせます。たとえば、必要な条件項目が制限の 10 個を超える場合、[国(請求先)] 項目と [都道府県(請求先)] 項目を組み合わせて 1 つの数式項目にすることもできます。

• 条件が取引先の関連レコードに基づく場合、積み上げ集計項目かトリガを使用して取引先オブジェクトにデータを移動します。次に、それらの項目を使用して、取引先割り当てルール条件を適用します。

データのクリーンアップに割り当てルールを使用しない

ダーティデータを整理するために (特にリードを関連付ける取引先を決定するときには) テリトリー割り当てルールの使用は避けてください。テリトリールール構造を効率化するために、データ整理はテリトリー割り当てエンジン以外で実行します。

テリトリー割り当てルールに関するメモ: 取引先レイアウトの項目 [テリトリーの割り当てルールから除外] がオンになっている場合、割り当てルールは起動しません。 

指定取引先を正しく定義する

テリトリー別に営業組織を管理する企業のほとんどに指定取引先があります。指定取引先とは、その管理に最も適任の営業担当に割り当てられた大口取引先です。標準の取引先割り当てルール構造内で指定取引先を定義するための主な戦略として、次のようなものがあります。

• ルール条件に取引先を名前で定義する。取引先名は非常に長くなる場合があるので、通常、この戦略は、テリトリー内に指定取引先がほどんど定義されていない小規模なお客様にお勧めします。

• 取引先名よりも簡潔な取引先番号に基づいて条件を定義する。この戦略により、組織はテリトリー内により多くの指定取引先を含めることができます。

• 上記のソリューションのいずれでも適切な拡張性が得られない場合は、カスタマイズしたソリューションを開発する。

ルールを使用したリードの割り当てを避ける

リードの割り当て時、標準のリード割り当てルールまたは別のカスタム割り当てプロセスを使用します。データを共有ルール構造に統合しないでください。共有ルール構造を使用する必要があり、リードの割り当てが比較的少なく、リードの再配置が不要な場合は、リード割り当てルールで標準取引先割り当てルールを使用することを検討します。

割り当てを取得するには、次の操作を行うトリガを作成します。

1. リードのデータを使用してダミー取引先を作成する

2. ダミー取引先に割り当てられたテリトリーにリードを共有する

3. ダミー取引先をロールバックしてシステムで作成されないようにする

このアーキテクチャと標準の取引先割り当てルールを使用してリード以外のオブジェクトを割り当てることもできます。

共有を使用して商談にフロート表示アクセスを提供する

商談にテリトリーをフロート表示する必要がある場合、テリトリー管理をカスタマイズすれば実現できますが、この種のカスタマイズは非常に複雑になり、管理が難しくなる可能性があります。

代わりに、プロファイル、共有ルール、または手動共有を設定してフロート表示アクセスを提供することを検討してください。

Force.com API を使用してルールのメンテナンスを自動化する

一部のお客様は、テリトリーの再配置を毎月、毎週、または毎日行い、きわめて大きなルールベースに更新情報を頻繁に送信しています。このようなお客様は、ルール構造を更新する自動化プロセスで効率化を図ることができます。Salesforce の標準ルール構造はリレーショナルで、幅広い顧客ベースに十分な柔軟性を提供します。規模の大きいお客様がこの標準ルール構造を維持することは、技術的には実現可能ですが、リレーショナル構造によって自動化メンテナンスが非常に複雑になります。

SOAP API または REST API を使用して標準の取引先割り当てルール構造のメンテナンスを自動化することを検討してください。可能であれば、標準ルール構造を非正規化してカスタムルール構造にすることは避けてください。