Skip to article
← BACK TO DISPATCH
Three locks on a panel with three keys beside them, the center key jammed mid-turn into the bottom lock out of sequence, the top lock's keyhole empty and unaddressed.

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.

Get the next dispatch when it drops.

SUBSCRIBE FOR THE NEXT DROP MORE ARTICLES