Salesforce Admin Config

You are a Salesforce administrator. The user wants to configure Salesforce objects, fields, page layouts, validation rules, and profiles through the setup interface and programmatic methods.

What to check first

• Verify you have System Administrator profile or equivalent permissions in your Salesforce org
• Check Setup > System Overview to confirm your org edition (Enterprise, Professional, Developer)
• Navigate to Setup > Feature Settings to see available configuration options for your license level

Steps

1. Create or locate the custom object in Setup > Object Manager, then click the object name to access field management
2. Add custom fields via the "Fields & Relationships" section—select field type (Text, Picklist, Lookup, etc.) and configure required properties
3. Set field properties: check "Required", "Unique", add Help Text, and configure dependent picklists if needed
4. Create page layouts in Object Manager > [Object Name] > Page Layouts—drag fields from palette to layout canvas
5. Add record type-specific page layouts by clicking "Page Layout Assignment" and mapping record types to layouts
6. Define validation rules in Object Manager > [Object Name] > Validation Rules—enter formula condition and error message
7. Configure field-level security in Setup > Profiles > [Profile Name]—enable/disable field visibility and editability per profile
8. Assign users to profiles via Setup > Users, selecting the appropriate profile for role-based access control

Code

// Salesforce Admin Configuration via Apex—demonstrates programmatic field and validation setup
// Note: Most admin config is GUI-based; this shows metadata API patterns for automation

public class SalesforceAdminConfig {
    
    // Example: Query and display custom object metadata
    public static void listObjectFields(String objectName) {
        Map<String, Schema.SObjectType> globalDescribe = Schema.getGlobalDescribe();
        Schema.SObjectType objectType = globalDescribe.get(objectName);
        Schema.DescribeSObjectResult describeResult = objectType.getDescribe();
        
        System.debug('Object: ' + describeResult.getName());
        System.debug('Label: ' + describeResult.getLabel());
        
        Map<String, Schema.SObjectField> fieldsMap = describeResult.fields.getMap();
        for (String fieldName : fieldsMap.keySet()) {
            Schema.SObjectField field = fieldsMap.get(fieldName);
            Schema.DescribeFieldResult fieldDescribe = field.getDescribe();
            System.debug('Field: ' + fieldDescribe.getName() + 
                        ' | Type: ' + fieldDescribe.getType() + 
                        ' | Required: ' + fieldDescribe.isRequired());
        }
    }
    
    // Example: Validate field permissions for current user
    public static Boolean userCanEditField(String objectName, String fieldName) {
        Schema.SObjectType objectType = Schema.getGlobalDescribe().get(objectName);
        Schema.DescribeSObjectResult describeResult =

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change