Enable security settings before you build anything. No, really.
Most Salesforce projects don't fail because of a technical misconfiguration. But sometimes they fail because someone made a series of reasonable-sounding decisions in the wrong order. This is about what happens when that wrong order puts the system’s security at risk.
There is a step in every greenfield Salesforce implementation that is both important, easy to perform, and routinely skipped.
Before any development begins - before you create a single sandbox, before you configure a single object, before you run your first Flow - you should enable all relevant security settings and Release Updates in Production. Not as a task on the backlog. Not as a "we'll get to that" item. As a prerequisite to everything else.
I don’t think this is a controversial position. Most experienced Salesforce implementers would nod along if you put it to them. And yet, in practice, it gets overlooked with surprising regularity.
Why it matters more than it sounds
Salesforce sandboxes are created as copies of Production. That means whatever security posture exists in your Production org at the point of sandbox creation is what gets inherited downstream. If those settings are not yet enabled, every sandbox you spin up will be working from the wrong baseline - and everything you build in them will be built against it.
The consequences tend to be invisible for a while. Development proceeds, the functional testing passes, and everything seems fine. Then, at some point, someone suggests enabling those security settings, and the atmosphere in the room changes. Because by that point, the plumbing is already in. The floors have been laid. Nobody wants to think about what "enabling the security settings now" actually means in practice.
What it means, in practice, is regression. Features that passed testing under a more permissive configuration may behave differently under the correct one. Automations, permission logic, integration behaviour - any of these can be affected. The team now faces a choice between proper remediation, or hoping for the best.
The specific failure I have seen
Years ago, I was brought in as a contributing consultant on a project that was deep into its delivery phase. During UAT, it became clear that the relevant security settings had never been enabled in Production - which meant they had never been active in any of the sandboxes, and everything had been built and tested against the wrong security baseline.
The right course of action would have been to enable those settings, retest, fix whatever (might've) broke, and go live with confidence. Instead, the lead consultant - understandably anxious about the short-term disruption - made the call to proceed as-is. The project went live with security settings that should have been active from day one sitting quietly disabled in the background.
Nobody celebrated that decision. It was a pragmatic response to a problem that should never have existed.
Why teams fall into this trap
I don’t think it’s laziness. I believe it is sequencing logic that feels reasonable, but is not. The thinking usually goes: we will set up the environments first, get building, and handle the security configuration once we know what we are dealing with. It sounds like a sensible division of concerns.
The problem is that security settings are not an overlay you can just apply to a finished system. They are part of the foundation. Enabling them late is the Salesforce equivalent of building a house and then trying to install the plumbing and wiring after the walls are up. Technically possible, but significantly more painful than it needed to be. And also entirely avoidable.
What good looks like
Before any sandbox is created:
- Enable the relevant security settings in Production
- Activate the applicable Release Updates, also in Production
- Confirm the Health Check baseline is where it should be. Where? In Production of course!
This takes a fraction of the time that retrofitting it later will cost. It means that when issues surface during sandbox development - and some will - they surface early, in low-stakes contexts, as a routine part of the build process rather than as a late-breaking emergency.
In the same spirit, give early thought to your object-level Organisation-Wide Defaults (OWDs). OWDs govern how records are shared across your org, and they sit at the base of your entire sharing and security model. Unlike the security settings above, it is not always practical to lock OWDs down before a single sandbox is created - the data model may not be sufficiently defined at that point. But they should be on your radar from the first week of development, not the last. Changing OWDs late in a project is not impossible, but it can trigger a cascade of sharing rule recalculations and unexpected access behaviour that is time-consuming to unpick and hard to explain to a client who thought testing was finished.
Issues found during unit testing are cheap. Issues found during UAT are expensive. Issues that make it to go-live are something else entirely.
The practical ask
If you run implementations, treat this as a prerequisite rather than a task. It should appear on your project initiation checklist alongside environment setup, not after it. It should be done before the first sandbox refresh or setup.
If you are joining a project mid-stream and this has not been done, raise it immediately. Do not wait for UAT to surface it. The earlier the conversation happens, the more options everyone has.
Security configuration is not the most glamorous part of a Salesforce implementation. But it is one of the few areas where getting the sequence wrong has consequences that compound quietly and surface loudly - usually at the worst possible moment.
Do it first, and do it in Production. Then build everything else on top of it - that’s what good security posture looks like.