Salesforce client work

Most Salesforce teams I work with don't need a new product. They need the org they already pay for to do more of the work. Sales and service people re-key the same data, copy records between Salesforce and other systems, chase updates by email, and build reports by hand because the data isn't where it should be. Each of those steps is small. Together they eat hours every week, and they are where mistakes come from.

Off-the-shelf apps rarely fit, because every org is shaped by years of its own objects, fields, sharing rules and integrations. The work is in understanding that shape and then automating inside it, without breaking what already works and without giving any automation more access than the people it serves.

This page describes that work. It is client work, so there is no repository, no live link and no client names. I describe the clients the way my experience entry does: enterprise clients in the US and APAC.

Since June 2018 I have worked as a Salesforce developer and integration engineer through consulting, leading Salesforce platform development and third-party integrations. The work falls into four areas.

• Flows and Apex automation. Replacing manual steps with record-triggered and autolaunched logic, in Flow where an admin should own the rule and in Apex where the logic needs code.
• REST/API integrations. Connecting Salesforce with the other platforms a business runs on, in both directions.
• Agentforce and AI in CRM. Bringing GPT and Claude into CRM workflows, and building with Agentforce.
• LWC and data work. Lightning Web Components for the screens people use every day, and the data work underneath them.

The one-sentence version: I make Salesforce do the repetitive work, connect it to everything else, and add AI where it saves real time.

Architecture

There is no single system to draw, so the diagram shows how the four areas sit inside a client's org rather than one data flow.

The common thread is the org itself. Every piece of work runs in the client's Salesforce org, under its security model. Automation runs inside the platform as Flows and Apex. Integrations cross the org boundary through APIs. AI features call an LLM provider or run through Agentforce. LWC sits in front of all of it for the people who use Salesforce every day.

The main trade-off I weigh on every engagement is Flow against Apex. Flow is the right choice when an admin owns a rule and changes it often. Apex is the right choice when the logic is complex, has to handle many records at once, or needs tests that prove it respects the user's access. I wrote this decision up for AI tools in Day 12 of my Headless 360 series (coming soon), and the same reasoning applies to ordinary automation.

The second trade-off is access. Integrations and AI features are tempting to run under one broad integration user. My rule is to run logic as the user who triggered it wherever the platform allows, so Salesforce's sharing and field-level security still apply. Day 11 (coming soon) covers this in detail for AI clients.

Stack

• Apex: business logic that needs code, bulk-safe and tested.
• Salesforce Flow: automation an admin can read and change.
• REST APIs: integrations between Salesforce and third-party platforms.
• Agentforce: Salesforce's own agent platform for AI inside the CRM.
• OpenAI and Anthropic APIs: GPT and Claude in CRM workflows.
• Lightning Web Components: the user interface on top of the data.

Key features

• Automation people don't notice. The best Flow or trigger is one the sales team never thinks about: the field is filled, the task exists, the record is routed.
• Integrations both ways. Data moves between Salesforce and the other platforms a client runs, so nobody copies it by hand.
• AI where it earns its place. GPT, Claude and Agentforce applied to specific CRM steps, not added for the sake of it.
• Screens built for the job. LWC components shaped around what a user does every day.
• Data that can be trusted. Data work so that reports and automation run on clean records.

Code or config highlight

Client code stays with clients, so this example comes from my own public material: the Apex in the Headless 360 capstone, as shown in Day 12 of the series (coming soon). It shows a pattern that carries straight over to client work: an invocable action that returns failures as data instead of throwing.

        } catch (QueryException e) {
            // WITH USER_MODE throws when the caller lacks object or field access.
            results = failAll(requests.size(), 'Salesforce denied access to the data this tool reads: ' + e.getMessage());
        } catch (Exception e) {
            // Return the problem to the agent instead of failing the whole MCP tool call.
            results = failAll(requests.size(), 'Account health could not be calculated: ' + e.getMessage());
        }
        return results;

The same action can run from a Flow, from an agent or from another Apex class. If it throws, the caller gets nothing useful. If it returns a clear message, a Flow can branch on it and an agent can repeat it to the user. Queries run in user mode, so a user without access gets an explanation, not data.

Results

These numbers are owner-reported and cover my Salesforce client work as a whole, not a single project.

• 15+ clients since 2018 (owner-reported).
• 200+ hours a month saved (owner-reported).
• 80% less manual work (owner-reported).

Lessons

Ask who owns the rule. Whether something should be a Flow or Apex depends less on what it does than on who will change it next year. Getting that wrong means either an admin waiting on a developer for every change, or code-level logic hidden in a Flow nobody can test.

Run as the user where you can. A broad integration user is convenient on day one and a security question for every review after. User mode and sharing keep the automation honest.

Integrations age. My early integrations from 2018 used Remote Site Settings and a custom setting for their configuration. Today the right tool is Named Credentials, so secrets stay out of code and custom settings.

Links

There is no repository or live link for client work. To see how I build, look at my public Salesforce material: the Headless 360 AI Assistant, the capstone of my 15-day Headless 360 series (coming soon); the CSV Parser with LWC tutorial component; and the early Salesforce integrations from 2018.