Claude for Salesforce: 7 Things to Build First

Most people who set up Claude for Salesforce stop one step too early. They get the connection working, ask it a few questions about their pipeline, watch it summarize a report correctly, and conclude that the AI is a very fast analyst. That is the least interesting thing it can do for you.

The interesting version starts when you stop asking questions and start handing over jobs — the ones that have been sitting in your backlog for a year because they each need a developer for an afternoon, and nobody has an afternoon of developer time to spare. Here are seven of them, in the order I’d actually do them.

A note before the list: none of this implies any affiliation between ORG Endgame, Salesforce, or Anthropic. Claude is one AI that can do this work. The list applies to any AI that can reach your org.

The part everyone stops at

Connecting an AI to your org is step one, and it is genuinely the easy step now — connecting Claude to a Salesforce org is a configuration exercise, not a project. What connection gets you is read access: the AI can query, summarize, and explain.

The gap between that and value is the gap between describing your org and changing it. An AI that can only read is a reporting tool with better manners. An AI that can write code, deploy it, and show you what it did is something else. Everything below assumes you’ve crossed that line.

1. The roll-up your object model won’t give you

Start here, because it’s the fastest proof and almost everyone has one. Somewhere in your org there’s a number a manager wants on a parent record — total value of open opportunities on an account, count of inspections on a property, last activity date across every child object — and Salesforce won’t roll it up because the relationship is a lookup, not a master-detail.

The usual answers are “restructure your data model” or “buy a rollup app.” The third answer is to build the trigger, which is a small, well-understood piece of Apex. It’s a two-hour job that has been waiting two years. Roll-ups without master-detail covers the shape of it.

2. Lead routing that matches the territory rules you actually have

Salesforce’s assignment rules are a straight-line list of criteria, evaluated in order until one matches — Salesforce’s own guidelines for assignment rules are worth reading if you’ve never hit their edges.

Real routing isn’t a straight line. It’s “by ZIP, unless the account already has an owner, unless that owner is out this week, unless the lead came from the partner form, in which case it goes to the partner queue regardless.” Every one of those clauses is where a rules table stops and code has to start. Describe the actual policy in plain English — including the exceptions you’d normally handle by hand — and have it built as code you can read back and correct.

3. The monthly cleanup that stops being a spreadsheet errand

If someone on your team exports records to a spreadsheet, fixes a field, and loads them back on a schedule, that’s not a task. That’s a job that hasn’t been built yet.

The tell is repetition. A one-time migration is a fine use of a CSV round-trip. The same round-trip every month means the rule lives in a human’s muscle memory instead of in your org, and the export is a stale snapshot you eventually write back over live data. Bulk updates without a Data Loader marathon walks through building it as a batch job — including the part where you count the population and verify the result before you trust it.

4. The custom object your process needs and the standard model doesn’t ship

Every business has one process that lives in a spreadsheet because it doesn’t map to Lead, Account, Opportunity, or Case. Inspections. Renewals. Compliance checks. Equipment. Whatever it is, your team tracks it outside the CRM, which means it isn’t reportable and isn’t automatable.

Building a custom object with the right fields, page layout, and relationships is a well-trodden path, and building a Salesforce custom object with AI shows what the generated metadata actually looks like when you read it line by line. The point isn’t that it’s hard. The point is that it’s small enough to never make the roadmap and valuable enough that skipping it costs you every quarter.

5. Renewal and follow-up alerts nobody has to remember

Most teams have at least one date-driven obligation held together by somebody’s calendar: renewals, expiring contracts, follow-ups that go cold at day fourteen, records that need a check-in ninety days out.

This is the cheapest possible build and one of the highest-leverage. A scheduled job that queries the population, applies your definition of “at risk,” and notifies the right person moves a responsibility out of a human’s head and into the system. It’s not clever. It’s just never anyone’s job to build, which is exactly the category this whole list is about.

6. The integration to the system your ops actually run on

Your CRM isn’t the only system your business runs on. There’s a dialer, or a project tool, or a billing platform, or an internal database, and the connection between it and Salesforce is currently a person copying fields between two tabs.

If the other system has an API, this is a build, not a purchase. The middleware market exists because writing integrations used to require a developer for a week; when the developer is an AI you brief in an afternoon, the calculus changes — which is most of the argument in what a Salesforce developer costs. Start with the one field that gets copied most often and expand from there.

7. The report you’ve been told you can’t build

Reporting is where the standard builder runs out most visibly: cross-object comparisons, calculations that need data from three levels down, “show me accounts with no activity in ninety days but an open opportunity.”

The answer is usually a query, not a report — and letting the AI write the SOQL turns a request you’ve been declining into a five-minute answer. When the question turns out to be a recurring one, the query becomes a scheduled job that populates a field, and now it is reportable through the standard builder. If you want more of these, Salesforce problems worth fixing is a longer bank of them.

What has to be true before any of this is a good idea

Every item above involves an AI writing to your production org, and that deserves more than optimism. Three things make it reasonable.

The changes deploy the way any professional Salesforce change deploys — through the Metadata API, sandbox-first, with tests. Every action is logged, so “what changed and who asked for it” is a question with an answer. And a snapshot is taken before deploys, so a change you regret is a change you can undo. That combination is what keeping AI-written changes safe actually means in practice.

What it does not mean: Sentinel will not stop your AI from building the wrong thing. If you describe a routing rule badly, you will get a badly routed lead — accurately deployed, fully logged, and reversible. The value is that mistakes are visible and recoverable, not that they’re prevented. Steps like reviewing what was generated and testing in a sandbox stay your job.

Where to start

Pick number one. A roll-up is small, its correctness is obvious at a glance, and shipping it tells you more about whether this works for your org than any amount of evaluation will. Then pick the item on this list your team complains about most.

Sentinel gives your AI the hands to do all seven — a dedicated server for your org, a real deploy path, and a log of everything it did. It’s $2,500 one-time onboarding on your first Sentinel, then $500/month per Sentinel.

Set up your Sentinel and hand your AI the first build →