S2Sの統合が必要だったので、それはいくつかのリリースでしたが、うまくいけば誰かがより効果的に解決できるという予期しない問題に遭遇しました。セールスフォース・セールスフォース往復フィールドの更新の問題
私はS2Sで連絡先を共有する2つの組織を持っています。
各組織の連絡先には同じスキーマがあり、標準フィールドとカスタムフィールドがあります。チェックボックスフィールドのA、および番号（18,0）フィールドB.は
組織1は、フィールドAを発行し、そしてB.
組織2サブスクライブをフィールドに加入：私はちょうど2つのカスタムフィールドを持つ基本ケースを再現しましたフィールドAに送信し、フィールドBを公開する。
Org 1は、S2Sを介してOrg 2への連絡先を共有することによって、すべてのS2Sワークフローを開始する。組織2は自動受諾をオンにしています。
Org 2にはフィールドBを使用するための単純なフィールドAを使用するInsert Before Insertトリガがあります。フィールドAがチェックされている場合は、フィールドBに2を設定します（チェックしないと0になります）。
すべてが動作しますOrg 2でうまくいく - 連絡先がフィールドAでうまくいき、フィールド結果がフィールドBに計算されるのが分かります。
結果フィールドBは自動で共有されません。次の連絡先の更新。 Org 2の "Description"のような同じ連絡先の非共有フィールドを編集するだけで簡単にできます。その後、以前に計算されたフィールドBの値がOrg 1にプッシュバックされます。
これは、フィールドBの計算がBefore Insert内で行われているため、S2S接続は現在の更新トランザクションが単独で実行されていると仮定しているためです（このロジックが無限のS2S更新を防止する方法を理解できますループ）。
フィールドBが変更されたときに（新しい、ダミーの）共有フィールドを強制的に更新するワークフローフィールド更新を作成しようとしましたが、それでもSalesforceと同じ実行コンテキストにあるため再共有を免除されているとみなされます。また、フィールドが変更されたときにリードを接続キューに転送し、それも機能しなかったワークフロールールを試しました。
その後、AfterUpdateトリガーで再更新ステートメントを試しました。共有フィールドが更新されている場合は、共有オブジェクトを再ロードして再更新します。それもうまくいきませんでした。
私は、BeforeUpdateトリガーによって共有フィールドが変更されたレコードをリロードして触れるAfterUpdateトリガーによって呼び出されるFutureメソッドである解決策を見つけました。これは、元の組織にフィールドの結果がほぼリアルタイムで表示されるようにします。
この解決策は今のところ私にとっては効果的ですが、何かが欠けているはずです。将来必要とされるよりも将来のコールやDMLが実行されるようになります。
誰ももっと優雅なソリューションを持っていますか？
私は '@ future'に固執します。私がこの機能のために開発者の靴を履いていたのであれば、Org 2で行われた更新が公開されたフィールドに無限ループの作成に関する懸念がないかどうかを確認していないでしょう。彼らがそのケースを処理しない場合、ループの可能性はなく、より簡単な開発者であり、次の機能に進む。私は '@ future'が好きです。なぜなら、副作用（将来のリリースでは予告なしに消える習慣が悪い）を利用せずに、 –