Platform Sharing Rules Generate
Published by dhoffritz in sf-skills
What this skill does
Use this skill when users need to create, generate, or modify Salesforce Sharing Rules metadata. TRIGGER when: users mention sharing rules, record sharing, criteria-based sharing, role-based sharing, guest user sharing, portal user sharing, sharingRules, sharingCriteriaRules, sharingGuestRules, sharingOwnerRules, .sharingRules-meta.xml files, or ask to share records with specific roles or groups. Also trigger when users want to configure record-level access beyond org-wide defaults (OWD), share
Add Platform Sharing Rules Generate to your agent
Review the source and files first. When you are ready, copy the prompt instruction or use the CLI command supported by your environment.
Install with a prompt
Paste this into a compatible coding agent:
add this skill "platform-sharing-rules-generate" from https://github.com/dhoffritz/sf-skillsInstall with the CLI
Run this command in a controlled environment after reviewing the repository:
npx skills add https://github.com/dhoffritz/sf-skills --skill platform-sharing-rules-generateSkill instructions
Sharing Rules Generator
Generate Salesforce Sharing Rules metadata to control record-level access beyond org-wide defaults. Supports criteria-based rules, role/group-based owner rules, and guest user rules for Experience Sites.
Scope
- In scope: Generating
sharingCriteriaRules,sharingOwnerRules, andsharingGuestRulesmetadata; retrieving existing sharing rules from an org; appending new rules to existing files; configuring rules for Guest and Portal profiles. - Out of scope: Changing org-wide defaults (OWD/sharing model), creating Experience Sites, configuring permission sets or profiles (use
platform-permission-set-generate), territory-based sharing rules.
Clarifying Questions
Before generating, confirm with the user if not already clear:
- Which object should the sharing rule apply to? (standard or custom object API name)
- What type of rule? (criteria-based, role/group-based owner rule, or guest user rule)
- Who should records be shared with? (role name, group, portal role, or guest user nickname)
- What access level? (Read or Read/Write)
- For criteria-based rules: what field conditions should match?
Required Inputs
Gather or infer before proceeding:
- Object API name: The sObject the rule targets (e.g.,
Account,Property__c) - Rule type: One of
sharingCriteriaRules,sharingOwnerRules, orsharingGuestRules - Shared-to target: Role, group, portal role, or guest user community nickname
- Access level:
ReadorEdit(maps to Read-Only or Read/Write) - Criteria (for criteria/guest rules): Field name, operation, and value for each filter item
Defaults unless specified:
- Access level:
Read includeRecordsOwnedByAll:truefor criteria rulesincludeHVUOwnedRecords:falsefor guest rules- Account sharing rules include
accountSettingswith all sub-access levels set toNone
Workflow
All steps are sequential. Do not skip or reorder.
Phase 1 — Discover
-
Resolve the SFDX project path — find the project's
sfdx-project.jsonand identify the package directory forsharingRules/. -
Check for existing sharing rules — look for
<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml. If found, read it to understand existing rules and avoid duplicates. -
If no local file exists, retrieve from the org:
sf project retrieve start --metadata "SharingRules:<ObjectName>" --target-org <org>
Phase 2 — Determine Rule Type
-
Select the rule type based on user intent. Read
references/rule-types.mdfor the complete schema of each type and its required elements. -
For Account sharing rules: the
accountSettingselement is required. Default sub-access levels toNoneunless the user specifies otherwise. -
For Guest rules: the
sharedTomust use<guestUser>with the site guest user's community nickname. Never use<role>or<group>for guest rules.
Phase 3 — Generate
-
Construct the XML following the schema in
references/rule-types.md. Key structure:- One
.sharingRules-meta.xmlfile per object - All rules for the same object go in the same file
- If appending to an existing file, add the new rule element inside the existing
<SharingRules>root
- One
-
Name the rule — derive
<fullName>from the intent (PascalCase, no spaces, descriptive). Generate a matching<label>in Title Case with spaces. -
Write the file to
<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml.
Phase 4 — Verify
- Run the verification checklist below before presenting output.
Verification Checklist
Universal Checks
- Does the file have the XML declaration and
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">root? - Is there exactly one file per object with all rules inside it?
- Does
<fullName>use PascalCase with no spaces? - Is
<label>present and human-readable? - Is
<accessLevel>one ofReadorEdit?
Criteria Rule Checks
- Is
<includeRecordsOwnedByAll>present (required boolean)? - Does each
<criteriaItems>have<field>,<operation>, and<value>? - Are picklist values valid for the target org?
Guest Rule Checks CRITICAL
- Does
<sharedTo>use<guestUser>(NOT<role>or<group>)? - Is
<includeHVUOwnedRecords>present (required boolean)? - Is
<includeRecordsOwnedByAll>ABSENT (only for criteria rules, not guest rules)?
Owner Rule Checks
- Does the rule have both
<sharedFrom>and<sharedTo>elements? - Do both use valid
<role>,<roleAndSubordinates>, or<group>targets?
Account-Specific Checks CRITICAL
- If object is Account, is
<accountSettings>present with all three sub-elements? - Are
<caseAccessLevel>,<contactAccessLevel>,<opportunityAccessLevel>all set?
Rules / Constraints
| Constraint | Rationale |
|---|---|
One .sharingRules-meta.xml file per object | Platform requirement — multiple files cause deployment errors |
Guest rules must use <guestUser> in sharedTo | Using <role> or <group> causes: "Specify a guest user's nickname for the guestUser field" |
Account rules require <accountSettings> | Without it: "AccountSettings is required for account sharing rules" |
includeRecordsOwnedByAll is required on criteria rules | Missing it causes: "Required field is missing: sharingCriteriaRules" |
includeHVUOwnedRecords is required on guest rules | Missing it causes deployment failure |
| Criteria field values must exist as picklist values on the org | Invalid values cause: "Picklist value does not exist" |
Never hardcode file paths — resolve from sfdx-project.json | Customer projects use custom package directories |
Gotchas
| Issue | Resolution |
|---|---|
Guest rule uses <role> instead of <guestUser> | Replace with <guestUser>CommunityNickname</guestUser> |
Account rule missing accountSettings | Add <accountSettings> with all three access level sub-elements set to None |
Criteria rule missing includeRecordsOwnedByAll | Add <includeRecordsOwnedByAll>true</includeRecordsOwnedByAll> |
| Picklist value mismatch | Query the org for valid values before generating criteria |
| Appending duplicates existing rule name | Check existing <fullName> values before writing |
| Guest user nickname not found | Query: SELECT CommunityNickname FROM User WHERE UserType='Guest' AND IsActive=true |
Output Expectations
Deliverables:
<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml— complete sharing rules file for the target object
Cross-Skill Integration
| Need | Delegate to |
|---|---|
| Permission set configuration | platform-permission-set-generate skill |
| Custom object creation (if target object doesn't exist) | platform-custom-object-generate skill |
Reference File Index
| File | When to read |
|---|---|
references/rule-types.md | Phase 2 — before generating any rule, to get the complete XML schema for each rule type |
Files included
- references/rule-types.md
- SKILL.md
More skills
Platform Sharing Rules Generate
forcedotcom/sf-skills
No summary provided.
Audit unavailable5.9k installsPlatform Custom Object Generate
forcedotcom/sf-skills
No summary provided.
Audit unavailable6.3k installsPlatform Metadata Api Context Get
forcedotcom/sf-skills
No summary provided.
Audit unavailable6k installs

