Skill v1.0.0
Automated scan100/100version: "1.0.0" name: generating-permission-set description: "Generates correct, deployable Salesforce permission set metadata (PermissionSet XML) with object, field, user, and app permissions. Use this skill when creating or editing permission set metadata, object permissions, field-level security (FLS), tab visibility, or deploying permission sets." compatibility: Salesforce Metadata API v60.0+ metadata: author: afv-library version: "1.0"
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>: - Formula fields cannot be editable
- Master-detail fields are required fields on the child (detail) object
<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: The tab is available on the All Tabs page and appears in the visible tabs for its associated app. Can be customized.Available: The tab is available on the All Tabs page. Individual users can customize their display to make the tab visible in any appNone: 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>
Step 8: Set Agent Access (Optional)
Enable access to Agentforce Employee Agents for users assigned to this permission set:
<agentAccesses> <agentName>Sales_Assistant_Agent</agentName> <enabled>true</enabled> </agentAccesses>
Field requirements:
- agentName (Required): The developer name of the employee agent
- enabled (Required): Set to true to grant access, false to deny
Important:
- Agent names must match existing Agentforce Employee Agent developer names
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