共有メカニズムの実装
具体的な共有ルールの実装方法と、ブランド内共有を実現するための詳細なメカニズムを解説します。
基本的な共有フロー
レコード作成から共有まで
ブランド内共有の実装
要件
同じブランドに属する複数のCommunity Userが、
相互にレコードを閲覧・編集できる例:
- Brand A の User1 がレコードを作成(Owner)
- Brand A の User2, User3 も閲覧・編集可能
- Brand B の User4, User5 はアクセス不可
実装方法
1. データ構造の準備
User → Contact → Account の関係:
User {
Id: "005...",
ContactId: "003...",
Contact: {
AccountId: "001XXX..." // Community Licensee Account
}
}Vendor Brand の設定:
Maker_Code__c {
Id: "a3x...",
Name: "Brand A",
Owner_Account__c: "001XXX..." // Community Licensee Account と同じ
}Design Family の設定:
Design_Family_Name__c {
Id: "a1x...",
Name: "Modern Chair Series",
OwnerId: "005...", // User1のID
Maker_Code__c: "a3x...", // Vendor BrandのID
Brand_Account_Id__c: "001XXX..." // 数式で自動計算
}2. Sharing Set Settingの設定
Profile: “R Design | Maker Community User”
Object: デザイン・ファミリー (Design_Family_Name__c)
Access Determined By:
User.Account = デザイン・ファミリー.Maker_Code__c.Owner_Account__cAccess Level: Read/Write
3. 共有判定ロジック
// 擬似コード
function canAccess(user, designFamily) {
const userAccountId = user.Contact.AccountId;
const recordOwnerAccountId = designFamily.Maker_Code__r.Owner_Account__c;
if (userAccountId === recordOwnerAccountId) {
return { access: true, level: 'Edit' };
} else {
return { access: false };
}
}主要オブジェクトごとの実装
Design Family (Design_Family_Name__c)
カスタムフィールド
<!-- Brand_Account_Id__c -->
<CustomField>
<fullName>Brand_Account_Id__c</fullName>
<formula>CASESAFEID( Maker_Code__r.Account__c )</formula>
<label>Brand Account Id</label>
<type>Text</type>
</CustomField>Sharing Set Setting
| 項目 | 設定値 |
|---|---|
| Object | Design_Family_Name__c |
| Access Determined By | User.Account = Design_Family_Name__c.Maker_Code__r.Owner_Account__c |
| Access Level | Read/Write |
Sharing Rules(補助的)
Allow Access by R. Modeling Team:
- 条件:
Allow_Access_by_R_Modeling_Team__c = True - 共有先: R.Design Support Team Portal Role
- アクセスレベル: Edit
Product (Product__c)
カスタムフィールド
<!-- Owner_Account__c -->
<CustomField>
<fullName>Owner_Account__c</fullName>
<label>Owner Account</label>
<referenceTo>Account</referenceTo>
<relationshipName>Product_Code</relationshipName>
<type>Lookup</type>
</CustomField>Sharing Set Setting
| 項目 | 設定値 |
|---|---|
| Object | Product__c |
| Access Determined By | User.Account = Product__c.Owner_Account__c |
| Access Level | Read/Write |
レコード作成時のロジック
// トリガーまたはFlowで設定
trigger ProductTrigger on Product__c (before insert, before update) {
for (Product__c prod : Trigger.new) {
if (prod.Product2_Brand__c != null) {
// Vendor BrandからOwner Accountを取得
Maker_Code__c vendorBrand = [
SELECT Owner_Account__c
FROM Maker_Code__c
WHERE Id = :prod.Product2_Brand__c
];
prod.Owner_Account__c = vendorBrand.Owner_Account__c;
}
}
}My Catalog (My_Catalog__c)
OWD設定
<CustomObject>
<sharingModel>ReadWrite</sharingModel>
<externalSharingModel>Private</externalSharingModel>
</CustomObject>意味:
- 内部ユーザー間: 全員が閲覧・編集可能
- 外部ユーザー間: 所有者のみ(追加の共有設定が必要)
Sharing Rules
AMOCC PTE. LTD.:
- 所有者: Executives(内部ユーザー)
- 共有先: AMOCC PTE. LTD. Portal Role
- アクセスレベル: Edit
R.Design Support Team:
- 所有者: Executives(内部ユーザー)
- 共有先: R.Design Support Team Portal Role
- アクセスレベル: Edit
Chatterコラボレーションの実現
要件
同じブランド内のユーザーが、Chatterで@mentionしてコラボレーション可能にする。
実装のポイント
1. レコード所有権
✅ レコード所有者 = Community User(実際の担当者)これにより:
- Chatter Feedにアクセス可能
- @mentionで他のユーザーを呼び出せる
- Follow機能で更新通知を受け取れる
❌ もし内部ユーザーが所有者だったら:
- Community Userは「編集権限を与えられただけ」の存在
- Chatterでの自然なコラボレーションが困難
2. レコードFeedへのアクセス
// Chatter Feedは、レコードへのRead権限があれば閲覧可能
// Sharing Set Settingで Read/Write権限を付与しているため、
// 同じブランドのユーザー全員がFeedにアクセス可能3. @mention機能
User1 (所有者): "@User2 このデザインを確認してください"
↓
User2 に通知が届く
↓
User2 はレコードにアクセスしてコメント返信必要な条件:
- User2 がレコードに対してRead権限以上を持つ ✅(Sharing Set Settingで付与)
- User1, User2 が同じCommunityに属する ✅
条件付き共有の実装
ユースケース
特定の条件を満たすレコードを、他のブランドやサポートチームと共有したい。
実装例: Allow_Access_by_R_Modeling_Team__c
1. カスタムフィールドの追加
<CustomField>
<fullName>Allow_Access_by_R_Modeling_Team__c</fullName>
<label>Allow Access by R. Modeling Team</label>
<type>Checkbox</type>
<defaultValue>false</defaultValue>
</CustomField>2. Criteria-based Sharing Ruleの作成
<sharingCriteriaRules>
<fullName>Allow_Access_by_R_Modeling_Team</fullName>
<accessLevel>Edit</accessLevel>
<sharedTo>
<portalRoleAndSubordinates>RDesignSupportTeam</portalRoleAndSubordinates>
</sharedTo>
<criteriaItems>
<field>Allow_Access_by_R_Modeling_Team__c</field>
<operation>equals</operation>
<value>True</value>
</criteriaItems>
<includeRecordsOwnedByAll>true</includeRecordsOwnedByAll>
</sharingCriteriaRules>3. 使用方法
Brand A User が Design Family を作成
↓
デフォルトでは Brand A 内でのみ共有
↓
サポートが必要な場合、"Allow Access by R. Modeling Team" をチェック
↓
R.Design Support Team がアクセス可能にControlledByParent による連鎖共有
概念
親レコードの共有設定が、自動的に子レコードに継承される仕組み。
実装例: Design Family → Design Version
親オブジェクト(Design Family)
<CustomObject>
<sharingModel>Private</sharingModel>
<externalSharingModel>Private</externalSharingModel>
</CustomObject>子オブジェクト(Design Version)
<CustomObject>
<sharingModel>ControlledByParent</sharingModel>
<externalSharingModel>ControlledByParent</externalSharingModel>
</CustomObject>効果
Brand A User が Design Family にアクセス可能
↓ 自動的に
Brand A User が関連する全 Design Version にアクセス可能階層構造:
Design_Family_Name__c (親)
└─ Design_Version__c (子)
├─ Design_Mesh_Junction__c (孫)
├─ Design_Product_Attribute_Junction__c (孫)
└─ Custom_Option_n_Design_Version_Junction__c (孫)注意: ControlledByParent を使用する場合、子オブジェクトには独自のSharing Rulesを設定できません。すべて親オブジェクトの設定に従います。
内部ユーザーからの共有
ユースケース
内部ユーザー(Executives, Managers)が作成したマスターデータを、特定のブランドと共有したい。
実装: Owner-based Sharing Rule
<sharingOwnerRules>
<fullName>Share_To_Brand_A</fullName>
<accessLevel>Edit</accessLevel>
<sharedTo>
<portalRoleAndSubordinates>BrandAStandard</portalRoleAndSubordinates>
</sharedTo>
<sharedFrom>
<roleAndSubordinates>Excecutives</roleAndSubordinates>
</sharedFrom>
</sharingOwnerRules>意味:
- Executives ロールのユーザーが所有するレコード
- Brand A Standard Portal Role とその配下のユーザーに共有
- Edit権限で共有
使用例
Category(カテゴリ)オブジェクト:
- 内部ユーザーがマスターカテゴリを作成
- 全ブランドに共有(Read Only)
- 各ブランドは参照のみ可能
パフォーマンス考慮事項
Sharing Set Settingsのパフォーマンス
Sharing Set Settingsは、ユーザーログイン時とレコードアクセス時に評価されます。大量のレコードがある場合、パフォーマンスに影響を与える可能性があります。
最適化のヒント
-
数式フィールドの活用
Brand_Account_Id__cのような数式フィールドを使用- 複雑なリレーションシップをフラット化
-
インデックスの活用
Owner_Account__cなどのルックアップフィールドは自動的にインデックス化- クエリパフォーマンスが向上
-
Sharing Rules の定期的な再計算
- Setup → Sharing Settings → “Recalculate” ボタン
- 大量のデータ変更後に実行
トラブルシューティング: 「共有されない」
診断チェックリスト
1. Owner_Account__c が正しく設定されているか?
SELECT Id, Name, Owner_Account__c, Maker_Code__r.Owner_Account__c
FROM Design_Family_Name__c
WHERE Id = 'a1x...'2. User の Account は正しいか?
SELECT Id, Name, Contact.AccountId, Contact.Account.Name
FROM User
WHERE Id = '005...'3. Account ID が一致しているか?
// 比較
Design_Family.Maker_Code__r.Owner_Account__c === User.Contact.AccountId4. Sharing Set Setting が適用されているか?
Setup → Sharing Settings → Sharing Set Settings
→ ユーザーのProfileを確認5. Sharing Records を確認
SELECT Id, ParentId, UserOrGroupId, AccessLevel, RowCause
FROM Design_Family_Name__Share
WHERE ParentId = 'a1x...'RowCause フィールドで、どの仕組みで共有されたかを確認:
Manual: 手動共有Rule: Sharing RuleImplicitChild: ControlledByParentTeam: Team SharingTerritoryManual: Territory
実装ベストプラクティス
1. カスタムフィールドの命名規則
✅ Owner_Account__c - 共有判定用
✅ Brand_Account_Id__c - 数式フィールド(ID取得)
❌ Account__c - 曖昧(用途が不明確)2. Sharing Rule のラベル
✅ "AMOCC PTE. LTD. パートナー ユーザ"
✅ "Allow Access by R. Modeling Team"
❌ "Rule1" - 用途が不明3. ドキュメント化
各Sharing Ruleには、以下を記録:
- 目的
- 対象ユーザー
- ビジネス要件
- 作成日・作成者
4. テスト
新しいブランドをオンボーディングする際:
- テストユーザーを作成
- Vendor Brand の Owner_Account__c を設定
- テストレコードを作成
- アクセス可能か確認
- 他のブランドからアクセス不可か確認
関連ドキュメント
- 前のステップ: 共有設定アーキテクチャ - 全体像
- 次のステップ: ライセンスとプロファイル - ユーザー設定
- 詳細: トラブルシューティング - 問題診断
更新履歴
- 2026年1月21日: 初版作成