afv-library/skills/permission-set-skill/SKILL.md

name	description	license	compatibility	metadata
permission-set-skill	Generate correct, deployable Salesforce permission set metadata with proper object, field, user, and app permissions. Use when generating permission set metadata.	Apache-2.0	Salesforce Metadata API v60.0+	author version afv-library 1.0

When to Use This Skill

Use when you need to generate metadata for a permission set or need to grant additional permissions such as:

• Providing temporary or project-based access
• Enabling feature-specific permissions
• Implementing role-based access control
• Extending profile permissions for specific user groups

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)
• Include purpose in description field
• Follow organization's naming standards

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>

Key considerations:

• Grant minimum necessary permissions (least privilege)
• Use viewAllRecords/modifyAllRecords sparingly
• Consider record-level security implications

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:

• Cannot set permissions on required fields, they are readable and editable by default
• Use format ObjectName.FieldName for field references
• Both readable and editable can be true (editable implies readable)

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 access
• ViewSetup: View Setup menu
• ManageUsers: User management
• RunReports: Report execution

Security review required for:

• ViewAllData: Read all records
• ModifyAllData: Edit all records
• ManageUsers: 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>

Tab visibility options:

• Visible: Always shown
• Available: Available but not default
• Hidden: Not visible

Important:

• Tab names should be same as the object API name, and tabs of custom objects end with "__c"

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:

• All required fields (fullName, label, description) are set
• Object permissions follow least privilege principle
• No field permissions on required fields
• System permissions (ViewAllData, ModifyAllData) are reviewed
• No duplicate permissions within permission set
• Description clearly states intended use case

Deployment

Deploy using Salesforce CLI:

sf project deploy start --metadata-dir force-app/main/default/permissionsets

Best Practices

• Granularity: Create focused permission sets for specific purposes
• Documentation: Maintain clear descriptions and naming
• Security: Never grant excessive permissions like ModifyAllData without justification