上流データの変更によるコミッションエンジン負荷の削減

上流のデータに対応する理由

手数料エンジンで実行される変換 (データ型の変換、リレーションを辿ってフラグの検索、テリトリークレジットを決定するためのルックアップ計算の実行) のたびに、メモリと時間が消費されます。手数料エンジンには、ステートメントごとに両方の固定割り当てがあります。この割り当てを超えると、ステートメントはタイムアウトするか失敗します。

オブジェクト マネージャ、フロー、またはApexを使用して、データ準備作業を上流のSalesforceに移行することで、コミッション エンジンがクリーンな事前作成済みデータを受け取り、データのクリーンアップではなくコミッション ロジックに集中できるようにします。

一般的な上流最適化シナリオ

次の 3 つのシナリオでは、データが Spiff に到達する前に上流でデータをアドレス指定する場合、最大のリターンが得られます。

• データ型の変換。Spiff では、日付、Boolean、通貨に特定のデータ型が使用されます。ソースデータが予期される型と一致しない場合、Spiff は処理されるすべてのレコードの計算時に各値を変換します。

  一般的な例として、DATETIME項目を Spiff が期間の比較に使用する DATE 形式に変換したり、ソースシステムが0および1として保存する Boolean 項目を Spiff のtrue / false値に変換したりします。

  データを同期する前に Salesforce フローまたは数式項目でこれらの変換を実行して、Spiff が最終形式で値を受け取るようにします。

• 関連オブジェクトのインジケータ フィールド。コミッションルールでは、特定の商品、カテゴリ、または条件がレコードに関連付けられているかどうかの確認が必要な場合があります。その情報が関連オブジェクトに存在する場合、Spiff は検索条件のすべてのレコードのリレーションを辿って条件を評価します。

  たとえば、注文に特定の商品種別が含まれている場合にのみ手数料を支払うルールでは、Spiff はすべての注文レコードの注文商品オブジェクトに注文オブジェクトを結合します。チェックボックスまたはインジケーター項目を注文オブジェクトに直接追加すると (商品の追加時にフローで設定)、そのリレーションのトラバースが完全になくなります。

  手数料ロジックで子オブジェクトの条件を確認する必要がある場合は、親オブジェクトにインジケーター項目を追加することを検討してください。

• テリトリーのクレジット処理。テリトリーベースの手数料の計算では、多くの場合、商談成立時に営業担当が属していたテリトリーと、その営業担当が負っているクレジットを判別するルックバックロジックが必要です。すべてのステートメントの手数料エンジン内でこのロジックを実行すると、計算に時間がかかります。

  より効率的な方法は、顧客が事前計算されたルックアップとしてテリトリー割り当てデータを提供することです。割り当てデータが Spiff の直接項目または関連オブジェクトとして使用できる場合、エンジンは値を計算するのではなく参照します。ステートメントの実行ごとに動的に計算するのではなく、定期的なデータ同期の一環としてこのデータを提供するように顧客と調整します。

上流データ管理のツール

次の Salesforce ツールを使用して、データが Spiff に到達する前にデータを準備します。

• オブジェクトマネージャー。数式項目、チェックボックス項目、またはカスタム項目を既存の Salesforce オブジェクトに追加して、事前計算された値またはインジケーターフラグを保存します。
• フロー。Spiff でレコードを作成または更新するときに、レコードトリガーフローを使用してインジケーター項目の入力、データ型の変換、計算値の記述を行います。
• Apex複雑な変換や一括処理の場合は、Apexトリガーまたはスケジュール済みApexを使用して、データをSpiffに同期する前にデータを大規模に準備します。

重要 上流データの変更を Salesforce システム管理者および手数料プラン所有者と調整します。取得元オブジェクトへの変更は、CRM プロセスと手数料の計算の両方に影響します。

実装前の上流の変更の計画

上流データの変更は、エンゲージメントの開始時に最も簡単に実装できます。手数料プランの完全なデータマッピングを確認します。また、型変換が必要な項目、リレーションのトラバースが必要な条件、事前計算済みデータとして提供するクレジット処理ロジックを特定します。