10 Salesforce Problems Worth Fixing This Quarter

Every org has a list. Not a written one — a spoken one, made of the things people stopped asking for because the answer was always the same. Most Salesforce problems on that list are not platform limitations. They are capacity limitations wearing a platform limitation’s clothes: each one needs a few hours of development, and a few hours of development has never been the kind of thing you can get scheduled.

Here are ten that show up in almost every org. None of them is exotic. Each is small enough that the reason it is still open has nothing to do with difficulty.

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

You want a number on the parent: total open value, count of inspections, most recent activity date. Salesforce roll-up summary fields do this — but only across a master-detail relationship. The official documentation is explicit: “The detail record must be related to the master through a master-detail relationship.”

Most real data models use lookups, because master-detail drags ownership and cascade-delete behavior along with it. So the number you want is not a configuration checkbox — it is a small piece of code that maintains a field. That is the entire gap between “we can’t do that” and a column on a report.

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

Assignment rules evaluate criteria in order and hand the record to whoever matches first. Actual routing rules are conditional: this zip goes to the west pod unless the account already has an owner, round-robin inside the pod but skip anyone out this week, escalate if nobody touches it in an hour.

What most orgs have instead is assignment rules plus a Flow plus one person who quietly fixes the misroutes. The fix is not more branches — it is writing the rule down once, as logic, in a place where anyone can read what it does.

3. The report you were told you can’t build

Some reports genuinely cannot be assembled in the report builder: comparisons across objects that aren’t related, calculations over a rolling window, a row-level number that doesn’t exist as a field anywhere. The standard answer is “export it to a spreadsheet,” which is why the number is stale by the time anyone reads it.

The fix usually isn’t a report at all. It is a field or a small object that holds the number, refreshed on a schedule, so the report builder finally has something to point at. If you want to see what the underlying question looks like as a query first, reading SOQL is a more useful skill than writing it.

4. Cleanup at volume, without the Data Loader marathon

The Data Import Wizard caps out at 50,000 records at a time — “You can import up to 50,000 records at a time” — and Data Loader means export, edit in a spreadsheet, re-import, with a nervous review pass in the middle.

For a one-time migration, fine. For “normalize the state abbreviations,” “fix the phone formats,” “reassign everything owned by people who left” — that is a recurring afternoon that never gets cheaper. Cleanup that repeats should be a job that runs, not a person with a CSV.

5. Duplicates caught on your rules, not the defaults

Salesforce ships duplicate and matching rules, and they handle the obvious cases well. What they do not handle is your definition of a duplicate: the same buyer under a different entity name, two contacts sharing a cell number, a new lead that actually matches an existing account rather than another lead.

Encoding the rule your business actually uses — and deciding what happens when it fires, whether that is block, merge, or flag for a human — is a build. It is a small build, and it is the difference between a dedupe policy and a dedupe hope.

6. Renewal and expiry alerts nobody remembers to send

Contract end dates, warranty windows, license renewals, permits, certifications. The data is already in the org. The alert isn’t. Most teams attempt this as a report subscription, and a report subscription is something people stop reading in about three weeks.

What the problem actually wants is a scheduled job that looks ahead, decides what is genuinely actionable, and writes a task or notifies the owner — with the 90/60/30 escalation you would have designed if anyone had asked you.

7. The custom object your process needs and Salesforce doesn’t ship

Standard objects describe a common shape of business. Yours has a step that shape doesn’t include: an inspection, a draw request, a placement, an intake, a site visit. The workaround is a spare field on Opportunity plus a shared understanding of what it means, which survives exactly until the person who understood it leaves.

An object with its own fields, layout, and validation is a day of work, not a quarter. We walked through building a Salesforce custom object with AI end to end, including reading the metadata it generates, precisely because this one is so common.

8. Approvals that outgrew the approval process

Linear approvals — rep, manager, done — are well served out of the box. Conditional matrices are where it breaks: amount and region and product line, skip legal when the paperwork is the standard template, route to a different VP when the first one is out.

Teams hit that ceiling and quietly move the approval into email, which means the approval no longer exists as a record of anything. That is not a governance problem to solve with policy. It is a modeling problem to solve with a build.

9. User onboarding and offboarding, end to end

Every new hire needs a user record, role, permission sets, queue membership, territory assignment, dashboard access, and a license. Every departure needs the reverse, plus record reassignment and open activity transfer — done the same way every time.

Run as a checklist, this is how permission drift happens: the steps someone skipped in March are invisible until an audit or an incident finds them. It should be a job that runs, with a record that it ran.

10. The integration with the system your ops actually run on

The stack that runs your business is rarely all Salesforce. There is a dialer, an accounting system, a scheduling tool, and something internal that predates everyone currently employed. Either no connector exists, or one exists and syncs whole objects when what you needed was one specific event moving in one specific direction.

Custom integration used to mean a vendor quote. It is now closer in size to the other nine items on this list.

What all ten have in common

None of these is hard. Individually they are hours of work, not weeks. They stay open because the smallest unit of Salesforce development you can realistically purchase is much larger than the job — what it costs to hire a Salesforce developer is the real reason a two-hour fix waits two quarters. The backlog is not a prioritization failure. It is an economics problem, and it is the same one every RevOps team runs into.

Which is why the list is worth revisiting now, rather than because anything about Salesforce changed. What changed is who can do the work.

Working the list instead of keeping it

When your AI can develop directly against the org — read the schema, write the code, deploy it — the ten items above stop being constraints and start being a queue you can burn down one afternoon at a time. That is what Sentinel is for: your AI gets hands in your CRM, through a connection you set up once.

The reason that is a reasonable thing to do rather than a reckless one is accountability, not restriction. Every action lands in an audit log, a snapshot is taken before deploys, and Salesforce changes go sandbox-first with tests. To be explicit about it: Sentinel does not prevent your AI from making a change you will regret. It makes that change visible and the previous state recoverable — which is a trade, and it is the honest one.

Pricing is $2,500 one-time onboarding on your first Sentinel, plus $500/month per Sentinel.

Pick the one item on your list that annoys you most this quarter and start there. Set up your Sentinel — onboarding included.