generating-permission-set

Original：🇺🇸 English

Translated

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.

2installs

Sourceforcedotcom/afv-library

Added on2026-04-19

NPX Install

npx skill4agent add forcedotcom/afv-library generating-permission-set

SKILL.md Content

View Translation Comparison →

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:

xml

<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:

xml

<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:

xml

<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

xml

<fields>
    <fullName>FieldName__c</fullName>
    <required>true</required>
</fields>

Use format
```
ObjectName.FieldName
```
for 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:

xml

<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:

xml

<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 app
```
None
```
: 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:

xml

<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:

xml

<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
```
__c
```
for custom objects, fields, tabs) cause failure.

Deployment

Deploy using Salesforce CLI