A Guide to Sharing Architecture (Salesforce, Winter ’24)

Type of Data Access

Record-level security lets you give users access to some object records, but not others. As with most applications, data access begins with a user. The application must know who the user is before it provides access. For Salesforce, there are different types of users and, sometimes, the level of access is different by type. Instead of reviewing every attribute of every license type, we’ll focus here on the interesting attributes that have significant impact on data access. Record ownership and full access are synonymous and interchangeable and provide the user with the highest level of access to a record.

レコードレベルのセキュリティを使用すると、ユーザーに一部のオブジェクトレコードへのアクセスを許可し、他のオブジェクトレコードへのアクセスは許可しません。ほとんどのアプリケーションと同様に、データアクセスはユーザーから始まります。アプリケーションは、アクセスを提供する前に、ユーザーが誰であるかを認識する必要があります。 Salesforce の場合、さまざまなタイプのユーザーが存在します。場合によっては、アクセスのレベルがタイプによって異なる場合があります。ここでは、すべてのライセンスタイプのすべての属性を確認するのではなく、データアクセスに大きな影響を与える興味深い属性に焦点を当てます。レコードの所有権とフルアクセスは同義で交換可能であり、ユーザーにレコードへの最高レベルのアクセスを提供します。

Users and Licenses

High-Volume Users

High-volume users (including users with the Customer Community, High Volume Customer Portal, and Authenticated Website license types) don’t utilize the sharing model, because their license types don’t support roles. These licenses have their own sharing model that works by foreign key match between the user (holding the license) and the data on Account and Contact lookups. Admins can create sharing sets or share groups to grant high-volume users access to records.

大規模ユーザー (カスタマーコミュニティ、大規模カスタマーポータル、および認証済み Web サイトのライセンスタイプを持つユーザーを含む) は、ライセンスタイプがロールをサポートしていないため、共有モデルを利用しません。これらのライセンスには、(ライセンスを保持している)ユーザーとアカウントおよびコンタクトのルックアップのデータ間の外部キーの一致によって機能する独自の共有モデルがあります。管理者は、共有セットまたは共有グループを作成して、大量のユーザーにレコードへのアクセスを許可できます。

Chatter Free and Chatter External Licenses
The Chatter Free and Chatter External licenses don’t follow the standard sharing model. These licenses don’t have access to CRM records (standard or custom objects) and Content functionality, and don’t support roles, therefore, there is no sharing.

Chatter Free ライセンスと Chatter Externalライセンスは、標準の共有モデルに従っていません。これらのライセンスは CRM レコード (標準オブジェクトまたはカスタムオブジェクト) およびコンテンツ機能にアクセスできず、ロールをサポートしていないため、共有はありません。

For the remainder of this document, we are assuming a Salesforce user type utilizing a full sharing model. See User Licenses for more information about each available license type.

このドキュメントの残りの部分では、完全共有モデルを利用する Salesforce ユーザータイプを想定します。利用可能な各ライセンスタイプの詳細については、「ユーザーライセンス」を参照してください。

Components

Profiles and Permission Sets

Profiles and permission sets provide object-level security by determining what types of data users see and whether they can edit, create, or delete records. For each object, the “View All” and “Modify All” permissions ignore sharing rules and settings, allowing administrators to quickly grant access to records associated with a given object across the organization. These permissions are often preferable alternatives to the “View All Data” and “Modify All Data” administrative permissions.
Profiles and permission sets also control field-level security, which determines the fields within every object that users can access. For example, an object can have 20 fields, but field-level security can be set up to prevent the users from seeing five of the 20 fields.

プロファイルと権限セットは、ユーザーが表示するデータの種類とレコードを編集、作成、または削除できるかどうかを決定することにより、オブジェクトレベルのセキュリティを提供します。各オブジェクトの「すべて表示」および「すべて変更」権限は共有ルールと設定を無視するため、管理者は組織全体の特定のオブジェクトに関連付けられたレコードへのアクセスを迅速に許可できます。これらの権限は、多くの場合、「すべてのデータの表示」および「すべてのデータの変更」の管理権限の代替として推奨されます。
プロファイルと権限セットは、フィールドレベルのセキュリティも制御します。それによりユーザーがアクセスできるすべてのオブジェクト内のフィールドを決定します。たとえば、オブジェクトには 20 個のフィールドを含めることができますが、フィールドレベルのセキュリティを設定して、ユーザーが 20 個のフィールドのうち 5 つを表示できないようにすることができます。

Record Ownership and Queues
Every record must be owned by a single user or a queue. The owner has access to the record, based on the Object Settings for the owner’s profile. For example, if the owner’s profile has Create and Read permission on an object, but not Edit or Delete permission, the owner can create a record for the object and see the new record. However, the owner won’t be able to edit or delete the record. Users higher in a hierarchy (role or territory) inherit the same data access as their subordinates for standard objects. Managers gain as much access as their subordinates. If the subordinate has read-only access, so will the manager. This access applies
to records owned by users, as well as records shared with them.
Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue.
If a single user owns more than 10,000 records, as a best practice:

The user record of the owner should not hold a role in the role hierarchy.
If the owner’s user record must hold a role, put the role at the top of the hierarchy in its own branch of the role hierarchy.

すべてのレコードは、1 人のユーザーまたはキューによって所有されている必要があります。所有者は、所有者のプロファイルのオブジェクト設定に基づいてそのレコードへのアクセス権を持ちます。たとえば、所有者のプロファイルにオブジェクトに対する「作成」権限と「参照」権限があるが、「編集」権限と「削除」権限がない場合は、所有者はオブジェクトのレコードを作成し、新しいレコードを表示できます。ただし、所有者は編集や削除ができません。階層 (ロールまたはテリトリー) の上位のユーザは、標準オブジェクトの下位ユーザと同じデータアクセス権を継承します。マネージャーは、部下と同じアクセス権を取得します。部下が読み取り専用アクセス権を持っている場合、マネージャーも読み取り専用アクセス権を持ちます。このアクセスはユーザーが所有するレコード、およびユーザーと共有されているレコードに適用されます。

キューは、ワークロードを共有するチームにレコードの優先順位を付け、配布し、割り当てるのに役立ちます。キューメンバーとロールの上位のユーザーリストビューからキューにアクセスし、キュー内のレコードの所有権を取得できます。

1 人のユーザが 10,000 件を超えるレコードを所有している場合、ベストプラクティスとして、次のことを行います。

• 所有者のユーザーレコードは、ロール階層でロールを保持しないでください。

• 所有者のユーザーレコードにロールを保持する必要がある場合は、そのロールをロール階層の独自のブランチの階層の最上位に配置します。

Organization-Wide Defaults
Organization-wide sharing settings specify the default level of access that users have to each others’ records. You use organization-wide sharing settings to lock your data to the most restrictive level. Use the other record-level security and sharing tools to selectively give access to other users. For example, users have object-level permissions to read and edit opportunities, and the organization-wide sharing setting is Read-Only. By default, those users can read all opportunity records, but can’t edit any unless they own the record or are granted other permissions. Organization-wide defaults are the only way to restrict user access to a record.

Organization-wide default settings can be changed from one setting to another (private to controlled by parent, then back to private); however, these changes require sharing recalculation and depending on volume could result in long
processing times.

For custom objects only, use the Grant Access Using Hierarchies setting, which if unchecked (default is checked), prevents managers
from inheriting access. This setting is found in the organization-wide default settings.

組織の共有設定では、ユーザーが互いのレコードに対して持つデフォルトのアクセスレベルを指定します。組織全体の共有設定を使用して、データを最も制限的なレベルにロックします。他のレコードレベルのセキュリティおよび共有ツールを使用して、選択的に他のユーザーにアクセスを許可します。たとえば、ユーザーには商談の読み取りと編集を行うためのオブジェクトレベルの権限があり、組織全体の共有設定は読み取り専用です。デフォルトでは、これらのユーザーはすべての商談レコードを読み取ることができますが、レコードを所有しているか、他の権限が付与されていない限り、レコードを編集することはできません。組織の共有設定は、レコードへのユーザーアクセスを制限する唯一の方法です。

組織の共有設定は、ある設定から別の設定に変更できます (“プライベート”から”親レコードに連動”にして、その後”プライベート”に戻る)。ただし、これらの変更には共有の再計算が必要であり、ボリュームによっては長時間かかる可能性があります。

カスタムオブジェクトの場合のみ、[階層を使用したアクセスの許可] 設定を使用します。これをオフにすると (デフォルトはオンになっています)、マネージャーはアクセス権の継承ができなくなります。この設定は、組織の共有設定にあります。

Role Hierarchy
A role hierarchy represents a level of data access that a user or group of users needs. The role hierarchy ensures that managers always have access to the same data as their employees, regardless of the organization-wide default settings. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.

An organization is allowed 500 roles; however, this number can be increased by Salesforce. As a best practice, keep the number of internal roles to 25,000 and the number of external roles to 100,000.

As a best practice, keep the role hierarchy to no more than 10 levels of branches in the hierarchy.

When a user’s role changes, any relevant sharing rules are evaluated to correct access as necessary. Peers within the same role don’t guarantee them access to each other’s data.

Modeling the role hierarchy begins with understanding how the organization is structured. This is usually built from understanding a manager’s scope, starting from the top. The CEO oversees the entire company. The CEO usually has direct reports that can then be segmented by Business Unit (Sales or Support) or geographical region (EMEA, APAC). That person then has direct reports that could be further segmented, and so on. Although this sounds very much like an HR organizational chart, when modeling data access, focus on data accessibility with a consideration to HR reporting.

Overlays are always the tricky part of the hierarchy. If they’re in their own branch, they’ll require either sharing rules, teams, or territory management to gain needed access. If they are folded into the hierarchy, there might be reporting implications.

It’s important to spend the time setting up the role hierarchy because it’s the foundation for the entire sharing model.

ロール階層は、ユーザーまたはユーザーのグループが必要とするデータアクセスのレベルを表します。ロール階層により、組織全体のデフォルト設定に関係なく、マネージャーは常に従業員と同じデータにアクセスできるようになります。役割階層は組織図と正確に一致する必要はありません。代わりに、階層内の各ロールは、ユーザーまたはユーザーのグループが必要とするデータアクセスのレベルを表す必要があります。

組織には 500 のロールが許可されます。ただし、この数は Salesforce によって増やすことができます。ベストプラクティスとして、内部ロールの数を 25,000 に、外部ロールの数を 100,000 に維持します。

ベストプラクティスとして、ロール階層は階層内のブランチレベルが 10 レベル以下に抑えてください。

ユーザーのロールが変更されると、関連する共有ルールが評価され、必要に応じてアクセスが修正されます。同じロール内のピアは、互いのデータにアクセスできることを保証しません。

ロール階層のモデル化は、組織がどのように構成されているかを理解することから始まります。これは通常、マネージャーの範囲を上から理解することから構築されます。 CEOは会社全体を監督します。通常、CEO には直属の部下がおり、ビジネスユニット (販売またはサポート) または地理的地域 (EMEA、APAC) ごとに細分化できます。その人物には直属の部下がおり、さらに細分化される可能性があります。これは人事組織図によく似ていますが、データアクセスをモデル化するときは、人事レポートを考慮してデータアクセシビリティに重点を置きます。

オーバーレイは常に階層の中で扱いが難しい部分です。自分のブランチにいる場合、必要なアクセスを取得するには、共有ルール、チーム、またはテリトリー管理のいずれかが必要になります。それらが階層に組み込まれている場合、レポートに影響を与える可能性があります。

Role Hierarchy Use Cases

Management access – the ability for managers to be able to see and do whatever their subordinates can see and do.

Management reporting – the ability for reporting to roll up in a hierarchical fashion so that anyone higher in the hierarchy sees more data than those below them.

Segregation between organizational branches – different business units don’t need to see each other’s data; having a hierarchy in which you can define separate branches allows you to segregate visibility within business units, while still rolling visibility up to the executive levels above those units.

Segregation within a role – in many organizations/applications, people who all play the same role should not necessarily see each other’s data. Having hierarchical roles allows you to define a “leaf” node in which all data is essentially private, and still roll that data up to a parent role that can see all.

管理アクセス – 管理者は、部下が表示および実行できるすべてのものを表示および実行できるようになります。

管理レポート – レポートを階層形式でロールアップする機能。これにより、階層の上位のユーザーには、その下のユーザーよりも多くのデータが表示されます。

組織のブランチ間の分離 – 異なるビジネスユニットが互いのデータを参照する必要がありません。個別のブランチを定義できる階層を使用すると、ビジネスユニット内の可視性を分離しながら、それらのユニットの上の経営幹部レベルまで可視性をロールアップできます。

ロール内での分離 – 多くの組織/アプリケーションでは、同じロールを担当する全員が必ずしもお互いのデータを参照できる必要はありません。階層的なロールを使用すると、すべてのデータが基本的にプライベートである「リーフ」ノードを定義し、そのデータをすべて表示できる親ロールにロールアップできます。

Public Groups

A public group (not a Chatter group) is a collection of individual users, roles, territories, and so on, that all have a function in common.
Public groups can consist of:

Users
Customer Portal Users
Partner Users
Roles
Roles and Internal Subordinates
Roles, Internal, and Portal Subordinates
Portal Roles
Portal Roles and Subordinates
Territories
Territories and Subordinates
Other public groups (nesting)
Groups can be nested (Group A nested into Group B), but don’t nest more than five levels. Nesting has an impact on group maintenance
and performance due to group membership calculation. As a best practice, keep the total number of public groups for an organization
to 100,000.

Public Groups Use Cases
When you need to provide access to an arbitrary group of people, you create a public group to collect them, and then use other sharing tools to give the group the necessary access. Group membership alone doesn’t provide data access.

Groups can also be nested inside each other, therefore, allowing a nested group to gain the same access as the group in which it is contained. This allows the creation of smaller, ad-hoc hierarchies that don’t necessarily interact with the role or territory hierarchies. If Group A is a member of Group B, then the members of Group A will have access to data shared to Group B at the same access level as the members of Group B.

Groups also have the ability to protect data shared in the group from being made accessible to people in the role hierarchy above the group members. This (and dealing with the access of record owners and their management hierarchy) allows the creation of groups in which very highly confidential information can be shared—the data will be accessible ONLY to group members, and nobody else in the organization. This is accomplished by using the Grant Access Using Hierarchies setting.

パブリックグループ (Chatter グループではない) は、共通の機能を持つ個々のユーザ、ロール、テリトリーなどの集合です。
パブリックグループは次のもので構成できます。

ユーザー
カスタマーポータルユーザー
パートナーユーザー
ロール
ロールと内部の部下
ロール、内部およびポータルの部下
ポータルのロール
ポータルのロール役割と部下
テリトリー
テリトリーと部下
その他の公開グループ (ネスト)

グループはネストできます (グループ A をグループ B にネスト) が、5 レベルを超えてネストしないでください。ネスティングはグループメンバーシップの計算を行うため、グループのメンテナンスとパフォーマンスに大きな影響があります。ベストプラクティスとして、組織のパブリックグループの総数を100,000までに維持してください。

Public Groups Use Cases

When you need to provide access to an arbitrary group of people, you create a public group to collect them, and then use other sharing tools to give the group the necessary access. Group membership alone doesn’t provide data access.

任意のユーザーのグループにアクセスを提供する必要がある場合は、パブリックグループを作成してユーザーを集め、他の共有ツールを使用してそのグループに必要なアクセスを付与します。グループのメンバーシップだけではデータにアクセスできません。

グループは相互にネストすることもできるため、ネストされたグループは、そのグループが含まれるグループと同じアクセス権を取得できます。これにより、必ずしもロール階層やテリトリー階層と相互作用しない、より小規模でアドホックな階層を作成できます。グループ A がグループ B のメンバーである場合、グループ A のメンバーは、グループ B のメンバーと同じアクセスレベルでグループ B に共有されているデータにアクセスできます。

グループには、グループメンバーより上位のロール階層内のユーザーがグループ内で共有されているデータにアクセスできないように保護する機能もあります。これ (およびレコード所有者とそのロール階層へのアクセスの処理) により、非常に機密性の高い情報を共有できるグループの作成が可能になります。データにはグループメンバーのみがアクセスでき、組織内の他の誰もアクセスできなくなります。これは、公開グループの設定にある「階層を使用したアクセスの許可」（Grant Access Using Hierarchies）設定（OFFにする）を使用して実現します。

Owner-Based SharingRules

Owner-based sharing rules allow for exceptions to organization-wide default settings and the role hierarchy that give additional users access to records they don’t own. Owner-based sharing rules are based on the record owner only.

Contact owner-based sharing rules don’t apply to private contacts.

The limit of owner-based sharing rules per object is 300.

所有者に基づく共有ルールを使用して、組織の共有設定およびロール階層に例外を許可し、所有しないレコードに対して追加のユーザアクセス権を付与できます。所有者に基づく共有ルールは、レコード所有者のみを基にしています。

取引先責任者の所有者に基づく共有ルールは、非公開の取引先責任者には適用されません。

オブジェクトあたりの所有者に基づく共有ルールの制限は 300 です。

Owner-Based Sharing Rule Use Cases

Role-based matrix management or overlay situations: a person in Service must be able to see some Sales data, but they live in different branches of the hierarchy, so you can create a rule that shares data between roles on different branches.

To provide data access to peers who hold the same role or territory.

To provide data access to other groupings of users (public groups, portal. roles, territories). The members of the groupings who own the records can be shared with the members of other groupings.

ロールに基づくマトリックス管理またはフロート表示の場合: サービス部門の社員が販売データを表示する必要がありますが、階層の異なるブランチに属している場合、ブランチが異なるロール間でデータを共有するルールを作成できます。

同じロールまたはテリトリーを持つ同僚にデータアクセスを提供します。

他のユーザグループ (公開グループ、ポータルロール、テリトリー) にデータアクセスを提供します。レコードを所有するグループのメンバーは、他のグループのメンバーと共有できます。

Criteria-Based Sharing Rules

Criteria-based sharing rules provide access to records based on the record’s field values (criteria). If the criteria are met (one or many field values), then a share record is created for the rule. Record ownership is not a consideration.

The limit of criteria-based and guest user sharing rules per object is 50.

条件に基づく共有ルールでは、レコードの項目値 (条件) に基づいて、レコードへのアクセス権が提供されます。条件 (1 つまたは複数の項目値) が一致すると、ルールに対して共有レコードが作成されます。レコード所有権は考慮されません。

オブジェクトあたりの条件に基づく共有ルールおよびゲストユーザ共有ルールの制限は 50 です。

Criteria-Based Sharing Rule Use Case

To provide data access to users or groups based on the value of a field on the record.

レコードの項目値に基づいて、ユーザまたはグループにデータアクセスを提供します。

ゲストユーザ共有ルール

A guest user sharing rule is a special type of criteria-based sharing rule used to grant record access to unauthenticated guest users. The limit of criteria-based and guest user sharing rules per object is 50.

ゲストユーザ共有ルールは、条件に基づく特別な種別の共有ルールであり、認証されていないゲストユーザにレコードへのアクセス権を付与するために使用されます。オブジェクトあたりの条件に基づく共有ルールおよびゲストユーザ共有ルールの制限は 50 です。

Warning

The guest user sharing rule type grants access to guest users without login credentials. By creating a guest user sharing rule, you’re allowing immediate and unlimited access to all records matching the sharing rule’s criteria to anyone. To secure your Salesforce data and give your guest users access to what they need, consider all the use cases and implications of creating this type of sharing rule. Implement security controls that you think are appropriate for the sensitivity of your data. Salesforce is not responsible for any exposure of your data to unauthenticated users based on this change from default settings.

ゲストユーザ共有ルールタイプは、ログイン情報のないゲストユーザにアクセス権を付与するものです。ゲストユーザ共有ルールを作成すれば、共有ルールの条件に一致するすべてのレコードに、誰もが無制限にすぐさまアクセスできるようになります。Salesforce データを保護し、ゲストユーザが必要な情報にアクセスできるようにするために、このタイプの共有ルールの作成に関するすべての使用事例と影響を検討してください。データの機密性に適したセキュリティコントロールを実装します。デフォルト設定からのこの変更により、認証されていないユーザにデータが漏洩した場合でも Salesforce は責任を負わないものとします。

Guest User Sharing Rule Use Case

To provide data access to unauthenticated guest users.

認証されていないゲストユーザにデータアクセス権を付与します。

Manual Sharing

Sometimes it’s impossible to define a consistent group of users who need access to a particular set of records. Record owners can use manual sharing to give read and edit permissions to users who don’t have access any other way. Manual sharing isn’t automated like organization-wide sharing settings, role hierarchies, or sharing rules. But it gives record owners the flexibility to share records with users that must see them. Manual sharing is available only in Salesforce Classic.

Manual sharing is removed when the record owner changes or when the sharing access granted doesn’t grant additional access beyond the object’s organization-wide sharing default access level. This also applies to manual shares created programmatically.

Only manual share records can be created on standard objects. Manual share records are defined as share records with the row cause set to manual share.

All share records (standard and custom objects) with a row cause set to manual share can be edited and deleted by the Share button on the object’s page layout, even if the share record was created programmatically.

特定のレコードセットに対するアクセス権限を必要とするユーザの一貫性のあるグループを定義することが必要な場合があります。レコード所有者は共有の直接設定を使用して、アクセス権限を持たないユーザに参照権限および編集権限を与えます。共有の直接設定は組織の共有設定、ロール階層、または共有ルールのように自動化されていません。ただし、レコード所有者に、レコードを参照する必要があるユーザとレコードを共有する柔軟性を提供します。共有の直接設定は、Salesforce Classic のみで使用できます。

レコード所有者が変更された場合や、付与された共有アクセス権ではオブジェクトに関する組織の共有設定のアクセスレベルを超える追加アクセス権が許可されない場合には、共有の直接設定は削除されます。これは、プログラムで作成される共有の直接設定にも適用されます。

標準オブジェクトで作成できるのは、共有の直接設定レコードのみです。共有の直接設定レコードは、共有理由が共有の直接設定に設定された共有レコードとして定義されます。

共有理由が共有の直接設定に設定されたすべての共有レコード (標準オブジェクトおよびカスタムオブジェクト) は、共有レコードがプログラムで作成された場合でも、オブジェクトのページレイアウトの [共有] ボタンを使用して編集および削除できます。

Manual Sharing Use Case

To provide the user with the ability to give access (read only or read/write) to the current record to other users, groups, or roles.

現在のレコードに対するアクセス権限 (「参照のみ」または「参照・更新」) を他のユーザ、グループ、ロールに付与する機能をユーザに提供します。

Teams

A team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the access level each team member has to the record. Some team members can have read-only access, while others have read/write.

Only owners, people higher in the hierarchy, and administrators can add team members and provide more access to the member. A team member with read/write access can add another member who already has access to the record with which the team is associated. The team member can’t provide them additional access.

Creating a team member in the app creates two records: a team record and an associated share record. If you create team members programmatically, you have to manage both the team record and associated share record. There is only one team per record (Account, Opportunity, or Case). If multiple teams are needed, depending on your specific needs, consider territory management or programmatic sharing

チームとは、取引先、営業商談、またはケースを担当するユーザで構成されるグループです。レコード所有者は、所有しているレコードごとにチームを作成できます。レコード所有者は、チームメンバーを追加し、レコードに対する各チームメンバーのアクセスレベルを指定できます。一部のチームメンバーには「参照のみ」権限を付与し、他のメンバーには「参照・更新」権限を付与できます。

チームメンバーを追加し、メンバーに他のアクセス権限を付与できるのは、所有者、上位階層のユーザ、およびシステム管理者のみです。「参照・更新」権限を持つチームメンバーは、チームが関連付けられているレコードに対してすでにアクセス権を持つ別のメンバーを追加できますが、そのメンバーに他のアクセス権限を付与することはできません。

アプリケーションでチームメンバーを作成すると、チームレコードと関連共有レコードの 2 つのレコードが作成されます。チームメンバーをプログラムで作成する場合は、チームレコードと関連共有レコードの両方を管理する必要があります。レコード (取引先、商談、ケース) ごとに 1 つのチームのみが存在します。複数のチームが必要な場合は、特定のニーズに応じてテリトリー管理またはプログラムによる共有を考慮してください。

Teams (Account and Opportunity) Use Cases

To provide the user with the ability to give access (read-only or read/write) to a single group of users (the team).

If teams are managed externally, say through an external commission or territory management system, then integration can be used to manage the account team. There are cases when territory management in an external system can align to a team solution within Salesforce.

Multiple owners of an account can be managed by the account team.

A single group of users (team) require either read-only or read/write access to an opportunity record. (Opportunity Team)

アクセス権限 (「参照のみ」または「参照・更新」) を 1 つのユーザグループ (チーム) に付与する機能をユーザに提供します。

外部コミッションやテリトリー管理システムなどによってチームが外部で管理される場合は、インテグレーションを使用して取引先チームを管理できます。外部システムのテリトリー管理を Salesforce 内のチームソリューションと連携できる場合もあります。

取引先の複数の所有者は、取引先チームで管理できます。

1 つのユーザグループ (チーム) には、商談レコードに対する「参照のみ」または「参照・更新」権限のいずれかが必要です (商談チーム)。

Territory Hierarchy

When using Enterprise Territory Management, you set up a territory hierarchy that shows a model’s territory structure and serves as its main interaction point. If Enterprise Territory Management is enabled, you must manage both the role hierarchy and territory hierarchy. For more information, see Enterprise Territory Management in Salesforce Help.

エンタープライズテリトリー管理を使用している場合は、モデルのテリトリー構造を表示し、メインの操作ポイントとしての役割を果たすようにテリトリー階層を設定します。エンタープライズテリトリー管理が有効な場合は、ロール階層とテリトリー階層の両方を管理する必要があります。詳細は、Salesforce ヘルプの「エンタープライズテリトリー管理」を参照してください。

Programmatic Sharing

Programmatic sharing (formally Apex-managed sharing) allows you to use code (Apex or other) to build sophisticated and dynamic sharing settings when a data access requirement cannot be met by any other means.

If you create a share record programmatically, and the out-of-box row cause (manual share) is used, then you can maintain this share record with the Share button in the app. The share record is subject to all rules with the manual share row cause such as deletion upon owner transfer.

Review Sharing a Record Using Apex before you consider using programmatic sharing.

プログラムによる共有 (以前はApex による共有管理) では、データアクセス要件を他の手段で満たすことができない場合に、コード (Apex またはその他) を使用して高度で動的な共有設定を作成できます。

共有レコードをプログラムで作成し、標準の共有理由 (共有の直接設定) を使用すると、この共有レコードをアプリケーションの [共有] ボタンで管理できます。共有レコードは、所有者の移行による削除など、共有の直接設定の共有理由に関するすべてのルールの対象になります。

プログラムによる共有の使用を検討する前に、「Apex を使用したレコードの共有」を確認してください。

Programmatic Sharing Use Cases

No other method of sharing (declarative) meets the data access needs.

There is an existing, external system of truth for user access assignments which will continue to drive access and be integrated with Salesforce.

Poor performance by using native sharing components. (Usually applies to very large data volumes)

Team functionality on custom objects.

他の共有方法 (宣言型) でデータアクセスのニーズが満たされない場合。

ユーザアクセスの割り当て用に既存の外部システムがある場合。このシステムはアクセスを引き続き制御し、Salesforce と統合されます。

ネイティブの共有コンポーネントを使用すると、パフォーマンスが低下する場合 (通常、データ量が多い場合)。

カスタムオブジェクトでのチーム機能。

Implicit Sharing

Implicit sharing is automatic. You can neither turn it off, nor turn it on—it is native to the application. In other words, implicit sharing isn’t a configurable setting; however, it’s important for any architect to understand. Parent implicit sharing is providing access to parent records (account only) when a user has access to children opportunities, cases, or contacts for that account. Salesforce has a data access policy that states if a user can see a contact (or opportunity, case, or order), then the user implicitly sees the associated account. Child implicit sharing is providing access to an account’s child records to the account owner. This access is defined at the owner’s role in the role hierarchy. Child implicit sharing only applies to contact, opportunity, and case objects (children of the account). The access levels that can be provided are View, Edit, and No access for each of the children objects when the role is created. By setting to View, the account owner can implicitly see the associated object records (contact, opportunity, or case). By setting to Edit, the account owner can implicitly modify the associated object (contact, opportunity or case).

Implicit sharing doesn’t apply to custom objects.

暗黙的な共有は自動的に行われます。オンまたはオフに設定することはできず、アプリケーションに対してネイティブに設定されます。つまり、暗黙的な共有は構成可能な設定ではありませんが、アーキテクトがこれを把握していることが重要です。親の暗黙的な共有では、ユーザが取引先の子の商談、ケース、または取引先責任者へのアクセス権を持っている場合に親レコード (取引先のみ) へのアクセス権が付与されます。Salesforce には、ユーザが取引先責任者 (あるいは商談、ケース、または注文) を表示できる場合には、関連する取引先も暗黙的に表示されることを示すデータアクセスポリシーがあります。子の暗黙的な共有では、取引先の子レコードへのアクセス権が取引先所有者に付与されます。このアクセス権は、ロール階層の所有者のロールで定義されます。子の暗黙的な共有は、取引先責任者、商談、およびケースオブジェクト (取引先の子) に対してのみ適用されます。ロールの作成時にそれぞれの子オブジェクトに付与できるアクセスレベルは、「参照」、「編集」、および「アクセス権限なし」です。アクセスレベルを「参照」に設定すると、取引先所有者は関連するオブジェクトレコード (取引先責任者、商談、またはケース) を暗黙的に表示できます。「編集」に設定すると、取引先所有者は関連するオブジェクトレコード (取引先責任者、商談、またはケース) を暗黙的に変更できます。暗黙的な共有は、カスタムオブジェクトには適用されません。

工事不要！契約期間縛りなし！【GMOとくとくBB光】月額3,430円（税込3,773円）〜！