少し面白いブログを見つけたので和訳しておきます。

DLRS フィールドをロックダウンし、検証ルールを使用して DLRS を適切に機能させる

したがって、DLRS フィールドがあり、常に DLRS によって制御される必要があるため、ユーザーにフィールドを更新させたくない場合があります。これは、フィールドレベルセキュリティ (FLS) を介して処理できます。DLRS は Apex で実行され、Apex はシステムモードで実行されます。つまり、FLS などは気にしません。つまり、すべてのプロファイルに対してフィールドを読み取り専用に設定でき、どのユーザーが DLRS をトリガーしても、DLRS はフィールドを更新できます。

これに対するもう 1 つの利点は、検証ルールをバイパスするように DLRS フィールドを簡単に設定できることです。DLRS 項目はシステムプロセス (Apex、ワークフロールール、プロセスビルダー、プロセスビルダーから起動されたフロー) によってのみ更新できることがわかったので、検証ルールに次のように記述できます。NOT(ISCHANGED(DLRS_FIELD__C))、つまり、フィールドが変更されていないとすると、NOT(FALSE) になります。これが TRUE になるため、検証ルールが正常に起動します。しかし、DLRS が起動すると NOT(TRUE) になり、これは False になり、検証ルールがバイパスされるため、DLRS は検証ルールによってロックされている可能性のあるレコードに対しても処理を続けることができます。

最初のリモートサイト設定エラー!

多くの人が、サンドボックスをスピンアップしたり、組織の移行を行ったりした後、DLRS が「Salesforce メタデータ API 接続に失敗しました。構成するには、以下のリンクをクリックしてください」という行に沿って警告メッセージをポップアップし続けることに気付きました。

DLRS はメタデータ API と連携して、トリガーを本番環境から本番環境に直接展開します。apex のデプロイを定期的に行う場合、これは非常に魔法のように機能します。これの鍵はリモートサイトの設定であり、DLRS がこれを行う方法は、クラスターにハードコードされた値を使用することです。クラスターを移動したり、サンドボックスを作成して DLRS アイテムをテストしたりする場合の欠点です。これを修正する 2 つの方法は、リモートサイトの設定を削除して DLRS に再作成させるか、リモートサイトの設定に移動してサーバーをあなたがいる現在のクラスター。たとえば、あなたがna2にいて、サンドボックスをスピンアップし、それがcs50であるとします。リモートサイトの設定に移動し、https://dlrs.na2.visual.force.com から https://dlrs.cs50.visual.force.com に変更すると、再び機能し始めるはずです。

子トリガーの欠落

新しい DLRS を保存しようとすると、次のようなエラーが表示されることがあります。

Active: Apex Trigger dlrs_contactTrigger has not been deployed. Click Manage Child Trigger and try again.

カスタムメタデータを使用している場合は、DLRS レコードが保存されるまで [子トリガーの展開] ボタンも表示されないため、展開する方法さえない場合、どのように保存するかについて少し混乱する可能性があります。これを簡単に修正するには、アクティブボックスのチェックを解除し、DLRS を保存し、子トリガーを展開してから、DLRS を編集し、アクティブボックスを再チェックします。

Im on DLRS (Enter Not Current Version Here) アップグレード方法を教えてください。

Git ページに移動して最新バージョンをインストールするだけで、自動的にアップグレードされます。より慎重な場合は、古いバージョンをアンインストールしてから、最新バージョンに更新できます。いつものように、最初にサンドボックスにインストールして、何も壊れないようにすることを強くお勧めします

トリガーをサポートしていないオブジェクトに関する子トリガーをデプロイするときにエラーが発生しましたか?

子トリガーをデプロイしようとすると、このエラーが表示される場合があり、次のようなエラーが表示される場合があります

Error:
triggers/dlrs_OpportunityCompetitorTrigger.trigger (Line: 4: Column:9) : SObject type does not allow triggers: OpportunityCompetitor

これは、オブジェクトがトリガーをサポートしていないことを意味し、スケジュール計算を使用するか、プロセスビルダーから DLRS を呼び出す必要があります。オブジェクトがトリガーを使用できるかどうかを確認するには、ワークベンチに移動し、[情報] をクリックして、オブジェクトが存在する場所を選択します。オブジェクトを選択して属性フォルダーをクリックし、「triggerable:True」を探します。

遭遇する可能性のあるもう 1 つの問題は、sObject タイプが挿入/削除/更新を許可しないことです。つまり、オブジェクトは特定のタイプの呼び出しのみをサポートします。これを修正するには、Process Builder を使用するか、DLRS トリガーを変更して、サポートされていないタイプの呼び出しで起動しないようにします。オブジェクトで何がサポートされているかを確認するには、開発者向け SOAP ガイドに、オブジェクトがサポートするもののリストが含まれている必要があります。

DLRS を使用してカウントする場合は、この 1 つのヒントに従ってください。

ほとんどのベストプラクティスは、Field To Aggregate を ID に設定することです。これにより、カウントする DLRS の問題のほとんどが修正されるようです。

What the hell? (Is this broken OR am I doing something wrong)?

そこで、ワークベンチに行ってリレーションシップクエリに取り組みましたが、うまくいきました。

Loads_To__c = ‘Highly Desirable’ OR Loads_From__c = ‘Highly Desirable’

しかし、それをDLRSに入れると、エラーが発生します! 一体何？

Error: Relationship Criteria ‘Loads_To__c = ‘Highly Desirable’ OR Loads_From__c = ‘Highly Desirable” is not valid, see SOQL documentation http://www.salesforce.com/us/developer/docs/soql_sosl/Content/sforce_api_calls_soql_select_conditionexpression.htm, error is ‘unexpected token: OR‘

答えは、DLRS の OR ステートメントはすべて括弧で囲む必要があるということです。したがって、次のように書き出す必要があります (Loads_To__c = 'Highly Desirable' OR Loads_From__c = 'Highly Desirable')。OR があり、その後に ANDS がある場合でも、DLRS がそれを受け入れるには、OR ステートメント全体をラップする必要があります。

DLRS をアンインストールしようとすると、トリガーがまだ存在することがわかります。どうすればそれらを取り除くことができますか?!

DLRS レコードに移動し、manage child トリガーをクリックします。すべてのトリガーを削除すると、アンインストールに進むことができます。DLRS レコードを既に削除している場合は、同じ子オブジェクトを指す新しいレコードを再作成してから、[子トリガーの展開] ボタンを使用してトリガーを削除できます。また、サンドボックスでそれらを削除してから、変更セットを使用して本番環境から削除することもできます。より慣れ親しんだ方法であれば、ワークベンチ経由で破壊的な変更セットを使用することもできます。

DLRSのヒント集