Skip to article
← BACK TO DISPATCH
A brass key-board of already-cut account keys with one already fitted into an open ledger cabinet, no new key being cut.

When a Salesforce deploy fails on permissions you already granted

The deploy succeeded. The data transfer failed. The error lied to me.

I'm not exaggerating. The log said object-level access denied. I'd checked that object twice. The integration user had full CRUD, clean profile, nothing visibly wrong. I kept orbiting the same layer because the error told me to.

Two hours in, I dropped one level deeper. Field-Level Security on the specific destination field the flow was writing to. Locked read-only for that profile. That's where the fault lived. The error had surfaced one layer above it, pointing me at the wrong scene entirely.

This is the thing that gets experienced teams, not just newcomers. Salesforce composes three permission layers at runtime (object CRUD, Field-Level Security, record access) and they don't fail in a tidy stack. They fail at whichever layer catches the request first. That isn't necessarily where the problem lives. The error is a symptom. The cause is somewhere else.

The fix took two seconds. The diagnosis took two hours. That ratio is the problem.

Once you have the composition sequence in your head, once you know an "object permission" error can actually live at the field level, and a field denial can be masking a record access rule downstream, that two-hour session compresses to five minutes. Every time. Not because the platform got simpler. Because you stopped trusting the layer the error reported and started asking which layer it came from.

That's not in a Trailhead badge. You learn it at 2am, with a failing deploy and someone waiting on the other side.

Part of Salesforce Architecture

Get the next dispatch when it drops.

SUBSCRIBE FOR THE NEXT DROP MORE ARTICLES