
Generate Permission Set
- 1 installs
- 787 repo stars
- Updated August 5, 2026
- forcedotcom/afv-library
Generates deployable Salesforce PermissionSet metadata XML with object, field-level, user, tab, and app permissions.
About
Produces correct PermissionSet XML with CRUD object permissions, field-level security, tab visibility, and app permissions for the Salesforce Metadata API. A developer uses it when creating or editing permission sets to grant access.
- Defines core properties, object permissions, and FLS in deployable XML
- Targets Salesforce Metadata API v60.0+
Generate Permission Set by the numbers
- 1 all-time installs (skills.sh)
- Ranked #3,836 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/forcedotcom/afv-library --skill generate-permission-setAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 787 |
| Last updated | August 5, 2026 |
| Repository | forcedotcom/afv-library ↗ |
What it does
Generates deployable Salesforce PermissionSet metadata XML with object, field-level, user, tab, and app permissions.
Files
When to Use This Skill
Use when generating or editing permission set metadata, or when granting object, field, user, and app permissions.
Step 1: Define Core Properties
Start by defining the required permission set properties:
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>YourPermissionSetName</fullName>
<label>Display Name for Administrators</label>
<description>Clear description of purpose and intended audience</description>
</PermissionSet>Naming conventions:
- Use descriptive API names (e.g.,
Sales_Manager_Access)
Step 2: Configure Object Permissions
Add CRUD permissions for standard and custom objects:
<objectPermissions>
<allowCreate>true</allowCreate>
<allowRead>true</allowRead>
<allowEdit>true</allowEdit>
<allowDelete>false</allowDelete>
<modifyAllRecords>false</modifyAllRecords>
<viewAllRecords>false</viewAllRecords>
<viewAllFields>false</viewAllFields>
<object>Account</object>
</objectPermissions>Step 3: Set Field-Level Security
Define field permissions for sensitive or custom fields:
<fieldPermissions>
<editable>true</editable>
<readable>true</readable>
<field>Account.SSN__c</field>
</fieldPermissions>Important:
- Required fields must NEVER appear in list of field permissions. Granting field-level security on required fields is not allowed by the platform and will cause deployment failure.
- Before adding any field, confirm from the object metadata that the field exists and is not required
- A field is required when its metadata contains
<required>true</required>:
<fields>
<fullName>FieldName__c</fullName>
<required>true</required>
</fields>- Use format
ObjectName.FieldNamefor field references - Set both readable and editable to true when the user needs edit access; editable implies readable
- If all fields should be visible, can alternatively enable the "viewAllFields" object permission
Step 4: Grant User Permissions
Add system-level permissions for features and capabilities:
<userPermissions>
<enabled>true</enabled>
<name>ApiEnabled</name>
</userPermissions>
<userPermissions>
<enabled>true</enabled>
<name>RunReports</name>
</userPermissions>Common permissions:
ApiEnabled: API accessViewSetup: View Setup menuManageUsers: User managementRunReports: Report execution
Security review required for:
ViewAllData: Read all recordsModifyAllData: Edit all recordsManageUsers: User administration
Step 5: Configure App and Tab Visibility
Make applications and tabs visible to users:
<applicationVisibilities>
<application>Sales_Console</application>
<visible>true</visible>
</applicationVisibilities>
<tabSettings>
<tab>CustomTab__c</tab>
<visibility>Visible</visibility>
</tabSettings>Application visibility options:
- <visible> can be true or false
Tab visibility options:
Visible: Always shownAvailable: Available but not defaultHidden: Not visible
CRITICAL - Tab Naming:
- Custom object tabs: MUST include the __c suffix (e.g., MyCustomObject__c)
- Standard object tabs: Use the object name with "standard-" prefix (e.g., standard-Account, standard-Contact)
- The tab name matches the object's API name exactly
Step 6: Add Apex and Visualforce Access (Optional)
Grant access to custom code:
<classAccesses>
<apexClass>CustomController</apexClass>
<enabled>true</enabled>
</classAccesses>
<pageAccesses>
<apexPage>CustomPage</apexPage>
<enabled>true</enabled>
</pageAccesses>Step 7: Set License and Record Type Settings (Optional)
Specify license requirements and record type visibility:
<license>Salesforce</license>
<hasActivationRequired>false</hasActivationRequired>
<recordTypeVisibilities>
<recordType>Account.Business</recordType>
<visible>true</visible>
<default>true</default>
</recordTypeVisibilities>Validation Checklist
Before deploying, verify:
- [ ] fullName, label, description set
- [ ] Permissions follow least privilege
- [ ] No required fields in
<fieldPermissions> - [ ] No duplicate permissions
- [ ] no lengthy comments
What Causes Deployment Failure
- Field permissions on required fields: Any required field in
<fieldPermissions>fails deployment. Required fields cannot have FLS; omit them entirely. Always confirm from object/field metadata that a field exists and is not required—never assume. - Incorrect API names: Using the wrong name or missing suffixes (e.g. missing
__cfor custom objects, fields, tabs) cause failure.
Deployment
Deploy using Salesforce CLI