generating-permission-set

$27

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

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

Application visibility options:

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

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

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