DEV Community: Kamal Thakur

The Hidden Salesforce Bottleneck Slowing Down Your Team

Kamal Thakur — Mon, 15 Jun 2026 13:05:23 +0000

Every Salesforce admin and developer I've talked to knows the feeling: it's Tuesday afternoon, you're three hours deep into manually tracing a CRUD conflict, and the feature your team actually needs to ship is still sitting untouched in the backlog.

That's not a skill gap. That's not a workflow problem. That's org tax — the invisible overhead that bleeds 12–15 hours a week from Salesforce teams, buried in manual data operations, permission audits, and metadata dependency mapping.

And the frustrating part? Most of it is work that shouldn't require a developer or admin at all.

What Org Tax Actually Looks Like

If you've worked in a Salesforce org of any real size, you've felt this:

Digging through Setup to understand why a permission set is silently breaking a field-level security rule
Tracing metadata dependencies before a deployment — manually, hoping nothing is missing
Asking "what exactly depends on this object?" and spending an hour in Workbench to find out
Reviewing org health with no structured audit trail, just institutional memory and fingers crossed

Each of these tasks is individually manageable. Together, they quietly consume the majority of your week — and they compound with every new admin, developer, or architect added to the team.

The Pattern No One Talks About

The Salesforce community is excellent at sharing how to do things — Flows, Apex patterns, LWC tricks, DevOps pipelines. Blogs like Salesforce Ben, Apex Hours, and SFDC Panther have built entire audiences on exactly that.

But there's a gap in the conversation around what we're wasting time on — the 80% of grunt work that's not in any certification curriculum and nobody blogs about because it's embarrassing to admit how manual it still is.

Nobody's writing "I spent 4 hours this week manually auditing sharing rules" — but everyone is doing it.

What Changes When You Kill the Grunt Work

This is where Autopex comes in.

Autopex is built specifically for Salesforce Admins, Developers, and Architects who are tired of trading productivity for visibility. It lets you:

Instantly detect and resolve CRUD conflicts — instead of hunting through overlapping permission sets and profiles by hand, Autopex surfaces conflicts immediately so you can fix, not find.

Get complete dependency visibility — data and metadata dependencies mapped and queryable, so you know the blast radius of any change before you make it.

Analyze your org with natural language — ask questions about your org the way you'd ask a colleague. No SOQL required. No 45-minute Workbench sessions.

The result: teams using Autopex report cutting org maintenance time by up to 60%.

To put that concretely — if your team is losing 15 hours a week to manual org ops, that's 780 hours a year. At 60% reduction, you get back roughly 470 hours. That's nearly three months of full-time work returned to actual development.

500+ Hours of Salesforce Work. Reduced to Just Minutes.

Watch a Demo

What Autopex Is Not

It's worth being clear about what this isn't, because the Salesforce tooling space has a lot of noise.

Autopex is not a replacement for your workflow. It doesn't swap out your CI/CD pipeline, your deployment tool (Gearset, Copado, Blue Canvas — use whatever fits), or your dev process.

It eliminates the invisible layer of work underneath your workflow — the part where admins and devs are context-switching into manual metadata archaeology instead of shipping features.

Think of it this way: your org finally becomes legible. You stop being the org's human search engine.

Who This Is For

Salesforce Admins managing org health and permissions across a growing user base — Autopex gives you audit-grade visibility without the audit-grade time investment.

Salesforce Developers who lose hours to understanding dependency chains before deployments — Autopex maps those for you, in seconds.

The Bigger Picture

The Salesforce ecosystem has gotten remarkably good at automation. Flows are more powerful than ever, Apex patterns are well-documented, and DevOps tooling has matured significantly. But most of that progress has been in how we build things.

The gap that remains is in how we understand and maintain what we've already built.

Org complexity only grows. Metadata accumulates. Dependencies multiply. And the default response — "just spend more time in Setup" — doesn't scale.

Autopex is a direct answer to that gap.

If you're a Salesforce Admin, Developer, or Business User who's curious to see what 60% less maintenance time looks like in practice,
check out Autopex and take it for a spin.

Salesforce Record Locking and Concurrency – Salesforce Things You should Know

Kamal Thakur — Tue, 07 Apr 2026 11:31:09 +0000

If you build on Salesforce long enough, you will hit a lock. This post explains how Salesforce Record Locking and Concurrency work, why you see UNABLE_TO_LOCK_ROW, and how to write code that behaves correctly under load.

Why Salesforce locks records

In a multi user system, two updates on the same record at the same time can corrupt data. To prevent that, Salesforce uses exclusive row locks:

When a transaction modifies a record, it takes a lock and holds it until the transaction ends.
Another transaction that tries to update the same record waits for about 10 seconds. If the lock is not released in time, Salesforce throws UNABLE_TO_LOCK_ROW.

Reads operations are different. A concurrent read operation sees the last committed version, not the in progress changes. That is normal isolation, meaning uncommitted changes are never visible to other transactions.

Reads vs writes in plain language

Writes (DML) take a lock. Other writers wait.
Reads (plain SOQL) do not lock and do not wait. They return the last committed data, which can be stale relative to an in flight update.
Reads with FOR UPDATE ask for the same exclusive lock that DML uses. If a lock is held, the query waits. When it acquires the lock, it reads the freshest committed data and keeps the lock for the rest of the transaction.

Quick comparison

The classic race condition Salesforce Record Locking

Start with an Opportunity where Amount = 100.

User A edits the Opportunity in the UI and saves Amount = 150. The write has started but is not committed yet. A holds the lock.
User B triggers a process to add 30. B runs a plain SOQL query and reads Amount = 100 because A’s change is not committed.
B sets 100 + 30 = 130 and tries to update. B waits for A’s lock.
When A commits, the row is 150. B’s pending update still writes 130, which is wrong. The expected result was 180.

Fix: make B read using FOR UPDATE so B waits, then reads the fresh value, then writes.

The right way to read before you write

Use FOR UPDATE when your logic must read a value and then write a value based on it, especially for money or counters.

public with sharing class OpportunityService {
    // Safely increment Amount by `delta` using FOR UPDATE
    public static void incrementAmount(Id oppId, Decimal delta) {
        // Simple retry for transient lock contention
        Integer maxAttempts = 3;
        for (Integer attempt = 1; attempt <= maxAttempts; attempt++) {
            try {
                Opportunity o = [
                    SELECT Id, Amount
                    FROM Opportunity
                    WHERE Id = :oppId
                    FOR UPDATE
                ];
                Decimal current = (o.Amount == null) ? 0 : o.Amount;
                o.Amount = current + delta;
                update o; // holds the lock until commit
                return;   // success
            } catch (DmlException e) {
                // Lock timeout or deadlock. Retry a couple of times.
                Boolean isLockIssue = e.getMessage().contains('UNABLE_TO_LOCK_ROW');
                if (!isLockIssue || attempt == maxAttempts) {
                    throw e;
                }
                // Optional: requeue work asynchronously instead of hot looping
            }
        }
    }
}

What this does:

The FOR UPDATE query waits if the record is locked.
When the query returns, you have the lock and a fresh value.
Your subsequent DML keeps the lock until commit, preventing other writers from sneaking in.

Practical guidance for Salesforce Record Locking

Keep transactions short. Do not do heavy work between query and DML.
Avoid long loops, large callouts, and complex triggers while holding locks.
Move DML to the end. Gather changes, then update once. This reduces lock time.
Use FOR UPDATE only when needed. Do not sprinkle it everywhere. Use it for read then write patterns where correctness matters, like financial amounts or inventory.
Be mindful of data skew. Avoid relating more than 10,000 child records to a single parent in lookups. Skew increases the chance of contention.
Handle lock errors. Catch UNABLE_TO_LOCK_ROW. Either retry a few times or requeue the work with Queueable so it runs later.
Batch safely. In batch or flows that touch many related rows, group by parent to reduce cross record contention.
Design idempotent operations. If a retry runs twice, it should not corrupt totals.

Debugging checklist for Salesforce Record Locking

Do you read a value and then write based on that value? If yes, consider FOR UPDATE.
Are you doing DML in multiple places in a single transaction? Consolidate.
Are you touching hot rows such as the same parent, the same owner, or the same counter object from many jobs? Stagger or shard the updates.
Are long running triggers, workflows, or flows holding locks? Trim the work or move it async.

TL;DR

Salesforce Record Locking and Concurrency are there to protect your data. Plain SOQL reads last committed data and does not wait. DML and FOR UPDATE take locks and wait. When you must read then write correctly under contention, query with FOR UPDATE, keep the transaction short, and update once. Handle UNABLE_TO_LOCK_ROW with small retries or by deferring work.

That is the stable pattern that keeps totals correct and errors rare.