
Generating Permission Set
Generate deployable Salesforce PermissionSet XML with correct object, field, tab, and app permissions for solo teams shipping on Salesforce.
Overview
Generating Permission Set is an agent skill for the Build phase that produces correct, deployable Salesforce PermissionSet XML including object, field, and app permissions.
Install
npx skills add https://github.com/forcedotcom/afv-library --skill generating-permission-setWhat is this skill?
- Step 1 core properties: fullName, label, and administrator-facing description in PermissionSet XML
- Object permissions block with create/read/edit/delete, modifyAllRecords, viewAllRecords, and viewAllFields
- Field-level security and additional permission sections follow structured XML patterns in the skill
- Naming convention guidance (e.g. descriptive API names like Sales_Manager_Access)
- Targets Metadata API v60.0+ deployable permission set packages
- Salesforce Metadata API compatibility: v60.0+
- Documented Step 1–3 flow for core properties, object permissions, and field configuration
Adoption & trust: 1.4k installs on skills.sh; 512 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need FLS and object access in a permission set but Metadata API XML is easy to get wrong and breaks deployments.
Who is it for?
Builders authoring Salesforce permission sets as source metadata for custom objects and standard objects in a known org model.
Skip if: Non-Salesforce stacks, high-level RBAC policy without XML output, or orgs where security is managed only via clicks with no metadata deploy.
When should I use this skill?
Creating or editing permission set metadata, object permissions, field-level security (FLS), tab visibility, or deploying permission sets.
What do I get? / Deliverables
You get structured PermissionSet XML with object permissions, field rules, and naming conventions ready to deploy via your Salesforce pipeline.
- PermissionSet XML with fullName, label, description, and objectPermissions blocks
- Field-level security entries aligned to the skill’s XML patterns
- Deploy-ready permission set package snippet for your Salesforce project
Recommended Skills
Journey fit
Permission set metadata is authored during build when wiring Salesforce security and deployable source—not during idea research or post-launch SEO. Salesforce Metadata API permission sets are integration-layer artifacts alongside objects, FLS, and tab visibility in org deployments.
How it compares
Deployable Salesforce metadata generator—not a generic IAM checker or MCP server for live org queries.
Common Questions / FAQ
Who is generating-permission-set for?
Solo builders and small teams shipping on Salesforce who maintain permission sets in source control and deploy with Metadata API v60.0+.
When should I use generating-permission-set?
During build integrations work when creating or editing permission set XML, object CRUD, field-level security, tab visibility, or pre-deploy packaging.
Is generating-permission-set safe to install?
The skill outputs permission metadata that can widen org access if misapplied—validate XML in sandbox and review Security Audits on this Prism page before production deploy.
SKILL.md
READMESKILL.md - Generating Permission Set
## 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 n