Salesforce Expert Consultant

An autonomous agent that designs and implements Salesforce solutions — configuring CRM workflows, building custom objects and flows, developing Apex code, integrating third-party systems, and optimizing the Salesforce platform for sales and service operations.

When to Use This Agent

Choose Salesforce Expert Consultant when:

• You need to configure Salesforce objects, fields, flows, or automation
• You want to develop custom Apex triggers, classes, or Lightning components
• You need Salesforce integration with external systems via API
• You are designing sales processes or service workflows in Salesforce

Consider alternatives when:

• You need CRM strategy without Salesforce specifics (use a general CRM consultant)
• You need sales coaching unrelated to CRM tooling (use a sales champion agent)
• You need data analytics beyond Salesforce reports (use a data analyst agent)

Quick Start

Copy
# .claude/agents/salesforce-expert.yml
name: salesforce-expert-consultant
description: Design and implement Salesforce solutions
agent_prompt: |
  You are a Salesforce Expert. Help with:

  1. Data model design (custom objects, relationships, fields)
  2. Process automation (Flow, Process Builder, Apex triggers)
  3. Custom development (Apex, LWC, Visualforce)
  4. Integration (REST/SOAP APIs, middleware, ETL)
  5. Reporting and dashboards
  6. Security model (profiles, permission sets, sharing rules)

  Best practices:
  - Click before code (use declarative tools when possible)
  - Follow the Salesforce Well-Architected framework
  - Bulkify all Apex code (handle 200+ records per trigger)
  - Write unit tests with 75%+ coverage
  - Use permission sets over profiles for granular access

Core Concepts

Salesforce Solution Architecture

Layer	Technology	Best For
UI	Lightning Web Components	Custom user interfaces
Automation	Flow Builder	No-code process automation
Logic	Apex	Complex business logic
Data	SOQL/SOSL	Data queries and search
Integration	REST/SOAP API	External system connectivity
Analytics	Reports & Dashboards	Business intelligence

Declarative vs Programmatic

Decision Tree: Clicks vs Code

  Can Flow Builder handle it?
    ├── YES → Use Flow (recommended)
    └── NO → Does it need complex logic?
        ├── YES → Write Apex
        └── NO → Can a formula field solve it?
            ├── YES → Use formula
            └── NO → Write Apex

Examples:
  "Send email when opportunity closes" → Flow (declarative)
  "Calculate weighted pipeline score" → Formula field (declarative)
  "Validate ZIP code against external API" → Apex trigger (code)
  "Real-time sync with ERP system" → Apex + Platform Events (code)

Apex Trigger Pattern

Copy
// Best practice: One trigger per object, handler class pattern
trigger AccountTrigger on Account (before insert, before update,
                                   after insert, after update) {
    AccountTriggerHandler handler = new AccountTriggerHandler();

    if (Trigger.isBefore) {
        if (Trigger.isInsert) handler.beforeInsert(Trigger.new);
        if (Trigger.isUpdate) handler.beforeUpdate(Trigger.new, Trigger.oldMap);
    }
    if (Trigger.isAfter) {
        if (Trigger.isInsert) handler.afterInsert(Trigger.new);
        if (Trigger.isUpdate) handler.afterUpdate(Trigger.new, Trigger.oldMap);
    }
}

public class AccountTriggerHandler {
    public void beforeUpdate(List<Account> newList, Map<Id, Account> oldMap) {
        // Bulkified: handles 1 or 200+ records
        List<Account> changedAccounts = new List<Account>();
        for (Account acc : newList) {
            if (acc.Industry != oldMap.get(acc.Id).Industry) {
                changedAccounts.add(acc);
            }
        }
        if (!changedAccounts.isEmpty()) {
            updateRelatedContacts(changedAccounts);
        }
    }
}

Configuration

Option	Type	Default	Description
edition	string	"enterprise"	Salesforce edition: professional, enterprise, unlimited
approach	string	"declarative-first"	Approach: declarative-first, code-first, hybrid
integrationPattern	string	"api"	Integration: api, middleware, platform-events
testCoverage	number	85	Target Apex test coverage percentage
bulkifyThreshold	number	200	Records per bulk operation
deploymentPipeline	string	"sandbox"	Pipeline: sandbox, scratch-org, devops-center

Best Practices

1. Declarative first, code second — Use Flow Builder, formulas, and validation rules before writing Apex. Declarative automation is easier to maintain, does not require unit tests, and can be modified by admins without developer support. Only write Apex when the logic is too complex for declarative tools.

2. Bulkify all Apex code — Salesforce triggers fire for batches of up to 200 records. Write every trigger, class, and method to handle bulk operations. Never put SOQL queries or DML operations inside loops. Use collections (Lists, Maps, Sets) to batch operations and stay within governor limits.

3. Use permission sets instead of profiles for access control — Profiles are broad and rigid (one per user). Permission sets are granular and stackable (multiple per user). Assign a minimal base profile and add specific capabilities through permission sets. This makes access management flexible and auditable.

4. Design data model before building automation — Object relationships, field types, and record types are hard to change once automation depends on them. Spend time getting the data model right first: define all objects, relationships (lookup vs master-detail), and required fields before building any flows or triggers.

5. Test in a sandbox that mirrors production — A sandbox with different data volume, user configurations, or installed packages produces misleading test results. Use a full-copy sandbox for UAT and ensure test data volumes match production. Deploy through a change set or CI pipeline, never directly to production.

Common Issues

Governor limits exceeded during bulk operations — Apex code hits the 100 SOQL query limit or 150 DML statement limit during data loads. Refactor to query and update in bulk: collect all IDs first, query once with WHERE Id IN :idList, process results in memory, then perform a single DML operation for all changes.

Flow runs multiple times causing duplicate records — A record-triggered flow fires on create and update, and the flow itself updates the record, triggering the flow again. Add an entry condition that checks for the specific field change that should trigger the flow, or use a static variable flag in Apex to prevent recursion.

Integration sync creates data inconsistencies — External system sends an account update that overwrites Salesforce data, or Salesforce changes are not reflected in the external system. Implement a "system of record" policy for each field: if Salesforce owns the field, external systems can read but not write it. Use timestamps to resolve conflicts and log all integration transactions for debugging.