共有更新の実行に関する考慮事項
共有の変更 (組織の共有設定、共有ルール、取引先の所有権、またはグループメンバーの更新など) を行う前に次の考慮事項を確認してください。
必要なエディション
| 使用可能なインターフェース: Salesforce Classic および Lightning Experience の両方 |
| 使用可能なエディション: Enterprise Edition、Performance Edition、Unlimited Edition、および Developer Edition |
全般
- 共有設定または関連機能 (グループ、ユーザー、テリトリー、またはロールなど) に対する特定の更新を行うと、レコードアクセス権が正しく評価されるようにグループメンバーまたは共有ルールの再適用が実行されます。組織の更新と設定の性質によっては、これらの共有の適用が完了するまでに時間がかかることがあります。
- 共有ルールの再適用が行われる設定の変更を次に示します。
- 組織のデフォルトの共有モデルの変更
- 共有ルールの作成、編集、または削除
- レコードの作成または移行
- 公開グループメンバーの更新
- ユーザーの作成または有効化
- ユーザーのロールの変更、またはロール階層の更新
- テリトリーのユーザーの追加または削除
- テリトリーの親の変更
- 共有ルールに関与するロール、テリトリー、または公開グループの変更
- グループメンバーの再適用が行われる設定の変更を次に示します。
- ロールの変更またはロールの親の変更
- テリトリーのユーザーの追加または削除
- 公開グループメンバーの更新
- ポータル取引先の所有権の更新 (新しい所有者のロールが異なる場合)
- グループメンバーまたは共有ルールの再適用が行われない設定の変更を次に示します。
- テリトリーの再配置
- 共有セットの更新
最適化
- [共有の適用を延期] 機能を有効にするには、Salesforce カスタマーサポートにお問い合わせください。共有再適用をトリガーする大規模または影響の大きい変更が必要で、タイムアウトやパフォーマンスの問題を回避するためにいくつかの自動共有適用を一定期間一時停止する場合、共有の適用を延期できます。詳細は、「共有適用の延期」を参照してください。
- 10,000 件を超えるオブジェクトレコードを所有しているユーザーがいると、パフォーマンスの問題が発生する可能性があるため、このようなユーザーがいるかどうかを確認します。共有更新を行う前に、レコードをより大きなユーザーグループに割り振ることをお勧めします。詳細は、『企業の規模に応じたレコードアクセス権の作成』ガイドの「所有権データスキュー」を参照してください。
- 10,000 件を超える子レコードに関連付けられている取引先があるかどうかを確認します。この場合も、パフォーマンスの問題が発生する可能性があります。共有更新を行う前に、レコードをより大きな取引先グループに割り振ることをお勧めします。詳細は、『企業の規模に応じたレコードアクセス権の作成』ガイドの「親子データスキュー」を参照してください。
- ロール階層を変更する場合、最初に下部 (リーフ) ノードへの変更を処理してから、重複処理を避けるために上に移動します。
- 階層内ですでにアクセス権を持っているユーザーにアクセス権を付与する共有ルールなど、アクセス権の重複パスを削除します。
共有適用の延期
- 共有適用の延期は、大規模なメンテナンス更新や、グループメンバーまたは共有ルールの再適用が必要な組織の再配置などの操作が対象となります。
- 設定の変更がわずかである場合でも、影響を受けるレコード数またはユーザー数が非常に大きい場合は共有の適用を延期することを検討します。たとえば、変更する共有ルールが数個のみでも、オブジェクトに大量のデータがある場合はこれに該当します。または、編集する必要がある所有者に基づく共有ルールが数個だとしても、この変更が、共有されるレコードを所有する多数のユーザーに影響する場合もこれに該当します。
- 共有設定の更新に直接関連していない変更も、共有の再適用に影響し、共有適用の延期の利点を得られる可能性があります。たとえば、多くの既存の共有ルールがある 1 つ以上のオブジェクトの大量のデータをアップロードする場合などがこれに該当します。
- 共有の適用を延期しても、データの整合性を維持するために一部の共有の変更の再適用は延期されません。サスペンドできないこれらの計算は、組織の設定とデータ量によっては処理に非常に時間がかかる可能性があります。共有の適用が延期されている間も、グループメンバーシップのロックは発生する可能性があります。
- 共有ルールの適用を延期すると、直接的または間接的に共有ルールを伴う更新のみが延期され、その他の共有関連の変更はすぐに処理されます。たとえば、共有ルールを作成したり、共有ルールで参照されているロールを更新したりすると、結果の再適用が一時停止されます。ただし、共有の直接設定を作成したり、チームやキューを更新したり、共有ルールで参照されていないロールを更新したりすると、それらの変更はすぐに評価されます。
- グループメンバーの適用を延期しても、個々のユーザーに関連するメンバーの変更はすぐに反映されます。ただし、ネストされたグループに関連するメンバーの変更やロール階層の変更は、グループメンバーの適用が再開されて完全な再適用が完了するまで反映されません。メンバーの変更によってレコードアクセス権が変更された場合も、適用が再開されて完全な再適用が完了するまで処理されません。
- 組織の変更および共有ルールの更新が、平日または活動の少ない期間にスケジュールできるぐらいに迅速に完了すると考えられる場合、共有適用の延期の利点を十分に得られる可能性は低いと思われます。
- 共有の適用を延期する場合は、グループメンバーまたは共有ルールの適用を再開した後に、常に共有ルールの完全な再適用を完了する必要があります。この再適用によって、すべての変更が共有ルールに反映されます。共有ルールの完全な再適用を実行しない場合、レコードアクセス動作に問題が発生する可能性があります。
- 変更を行った直後に共有の適用を再開することをお勧めします。その後、活動の少ない期間にできるだけ早く共有ルールの完全な再適用を開始します。共有をすぐに再開すると、新しい更新がすぐに処理されます。つまり、再適用する必要がある変更が少なくなります。共有の完全な再適用を適時に完了することで、大幅な遅延時間が発生することなくレコードアクセス権が期待どおりに動作します。
テスト
- 本番組織でこれらの変更を行う前に、Full Copy Sandbox で更新をテストします (該当する場合は共有再適用の再開を含む)。このテストでは、時間かかる可能性がある潜在的な問題を特定し、本番環境のプロセス全体にかかる時間を推定できます。
- Full Copy Sandbox は、現在の商品環境をできるだけ模倣する必要があります。過去 30 日以内に更新された Sandbox を使用することをお勧めします。また、Sandbox にはすべての主要な変更が反映されている必要があります。
タイミング
- 変更と共有の再適用を完了できる十分な長さのメンテナンス実施期間を計画します。
- 週末など組織の活動の少ない期間にメンテナンス実施期間をスケジュールします。
この記事で問題は解決されましたか?
ご意見をお待ちしております。
