共有メカニズムの実装

具体的な共有ルールの実装方法と、ブランド内共有を実現するための詳細なメカニズムを解説します。


基本的な共有フロー

レコード作成から共有まで


ブランド内共有の実装

要件

同じブランドに属する複数の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__c

Access 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

項目設定値
ObjectDesign_Family_Name__c
Access Determined ByUser.Account = Design_Family_Name__c.Maker_Code__r.Owner_Account__c
Access LevelRead/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

項目設定値
ObjectProduct__c
Access Determined ByUser.Account = Product__c.Owner_Account__c
Access LevelRead/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は、ユーザーログイン時とレコードアクセス時に評価されます。大量のレコードがある場合、パフォーマンスに影響を与える可能性があります。

最適化のヒント

  1. 数式フィールドの活用

    • Brand_Account_Id__c のような数式フィールドを使用
    • 複雑なリレーションシップをフラット化
  2. インデックスの活用

    • Owner_Account__c などのルックアップフィールドは自動的にインデックス化
    • クエリパフォーマンスが向上
  3. 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.AccountId

4. 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 Rule
  • ImplicitChild: ControlledByParent
  • Team: Team Sharing
  • TerritoryManual: 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. テスト

新しいブランドをオンボーディングする際:

  1. テストユーザーを作成
  2. Vendor Brand の Owner_Account__c を設定
  3. テストレコードを作成
  4. アクセス可能か確認
  5. 他のブランドからアクセス不可か確認

関連ドキュメント


更新履歴

  • 2026年1月21日: 初版作成