mirror of
https://github.com/forcedotcom/afv-library.git
synced 2026-07-30 03:09:50 +08:00
W-21367283: Add skills for metadata permission set generation (#23)
* initial skill for perm sets * more edits * changes after testing * more changes * address comments * standard tabs should have prefix * remove apache license --------- Co-authored-by: irisli <irisli@salesforce.com>
This commit is contained in:
parent
ff08ad58e2
commit
ae4e46d97f
171
skills/generate-permission-set/SKILL.md
Normal file
171
skills/generate-permission-set/SKILL.md
Normal file
@ -0,0 +1,171 @@
|
||||
---
|
||||
name: generate-permission-set
|
||||
description: Generates correct, deployable Salesforce permission set metadata (PermissionSet XML) with object, field, user, and app permissions. Use when creating or editing permission set metadata, PermissionSet XML, 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:
|
||||
|
||||
```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>`:
|
||||
```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`: Always shown
|
||||
- `Available`: Available but not default
|
||||
- `Hidden`: 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>
|
||||
```
|
||||
|
||||
## 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
|
||||
Loading…
Reference in New Issue
Block a user