Too many times we've had developers (as well as our release manager, who also dev's) inadvertently make a change directly in Production because they had the Prod org open alongside their dev org in the browser. It took us weeks to discover several validation rules had been unintentionally deactivated. Mere training/vigilance isn't good enough to prevent this behavior reliably.

What is a good, low-cost (preferably automated) way to guard against the human errors of making changes directly in Prod?

We're a relatively small team, so solutions that are costly to implement aren't viable for us.

Solutions under consideration: (don't like any of these)

  • Change the Themes & Branding color in every sandbox after creation/refresh (Con: don't see a way to automate this)
  • Retroactively scan for accidental changes by periodically retrieving "all" metadata from Prod to identify diffs in source control that didn't go through the change control process (Con: it's retroactive [not proactive], it's a manual step, and it would involve adding metadata types to source control that we don't currently track)
  • Remove admin privileges from individual developers' user accounts in Production, using a single service account User for deployments (Con: involves extra license $, post-sandbox-refresh script to grant devs admin access in LLEs)
  • 1
    Partial answer: we use Gearset to run unit tests every night in PROD; If you had apex regtests that cover the VRs and other things you are worried about (automations); you could detect many inadvertent PROD changes. Similarly, you could use a UX testing tool that ran on a schedule to verify other inadvertent changes
    – cropredy
    Dec 16, 2021 at 5:05
  • 2
    Gearset on the Enterprise tier offers a change feature... so you can get a report each day on what has changed in PROD. really helpful. Dec 17, 2021 at 16:31
  • Did not know that, @dbwood3. Sounds like a useful feature Dec 18, 2021 at 4:40

3 Answers 3


We're a relatively small team, so solutions that are costly to implement aren't viable for us.

It's up to your team to decide if the cost is worth removing the risk that accidently doing something in production could have. You seem to suggest it's happening often so you need to implement a solution, but I'd question why it isn't getting better on its own.

I certainly have done this accidently, but can't say it has happened more than a couple times. In those incidences, I do think the working norms of the team contributed to it occuring

  • Sometimes doing changes directly in production (ex. oh, it's a simple change)
  • Not having another person test every single change before it goes to production
  • Not documenting all changes or what is expected to be changed

Based on your example, I'd press why it took weeks to realize a validation rule was deactivated in production instead of, presumably, a testing environment? If the validation rule was deactivated in production (instead of a QA org), then someone checking the work should have caught it pretty quickly. You may think it's overkill for making simple changes, but your specific issue is the exact reason you always have someone else other than the dev check their work...because of human error. It's not atypical to see mistakes occur on the simplest of changes

  • Misspelling label changes
  • Wrong order of picklist values
  • Page Layout order

No matter how simple or complex the change, someone else should be checking the work against what the expected change should be (acceptance criteria).

Otherwise, changing how you work could help to minimize how someone may have production open or accidently click on the wrong domain link:

  • Working in more scratch orgs (if possible)
  • Using IDE as one-stop shop (ex. open org from VS Code)
  • Removing solutions that may accidently redirect to production (links/references in hyperlinks, emails, etc in a sandbox).

That last one can be quite tricky if you, while working or testing something, get redirected to production without realizing it. That doesn't sound like what happened for you, but something to consider.

For Admins, you could also take the following approaches:

  • Set one person as rotating "production support" and have that person only focus on production for that day, week, etc. Limit the occurrence of them having to be in production and doing work in a sandbox.
  • What permissions do they actually need? What changes are they expected to make? Could they get away with limited permissions that would still allow them to make dashboards and reports?
  • Going off the above and assuming they do need to make setup changes in sandboxes, you could take your final solution (post-sandbox refresh script) to assign a permission set to your Admin users (add them to a public group) that will give them the "setup" permissions needed just for sandboxes. It's kind of a half-measure, but this is assuming Admins are more at risk for this type of error because they have to be in production at times and they can't adopt all the benefits of the developer workflow mentioned above.
  • 1
    Definitely recommend using sfdx, it's so much harder to "accidentally" modify production with some discipline. Unfortunately, getting to sfdx-only can be a challenge.
    – sfdcfox
    Dec 15, 2021 at 21:54
  • Thanks for the thoughtful answer. The top half of your answer doesn't apply (a good answer to a different question), but the 2nd suggestion in the bottom half may be a solution for the dev members of our team (4 of 7). It isn't reasonable to have the other 3 use a CLI or VS Code to open orgs, unfortunately, and they're often in Prod for good admin reasons (reports, data quality checks, user support, issue investigation, etc.). Dec 16, 2021 at 5:41
  • 1
    First half was just me assuming someone testing the expected change would've realized that work wasn't done where it was supposed to be - admittedly, it was a guess it'd apply to your situation although would be helpful in general to reiterate to anyone stumbling upon it. I updated a bit at the end based on your info about your admins needing to be in production for good reason. Dec 16, 2021 at 13:21

I've found a Chrome Extension that changes the color of Salesforce's logo on the tabs and adds a thin line at the top of the page in the same color is all I needed to stop this issue. I use Salesforce Organizer (https://organizer.solutions/donate.html)

PROD is always red. From light to dark colors, I move from sandbox to develop to stage.

My current tabs

enter image description here

Since implementing this two or so years ago, I have not had any issues (knock wood)...

If your organization locks down Extensions, then I would put in place a dev ops tool like GearSet, https://gearset.com/. Not only will it allow fast deploys to PROD from various places it can track metadata in PROD and let you know if anything has changed as often as you like.

note: I'm involved in neither company, though I did get swag (a hat, candy, etc) from GearSet for attending a focus group. :-)

  • Also... I had to open PROD for the example above... the rest of the tabs were open. This points out the other important thought. WHY DO YOU NEED A PROD WINDOW OPEN? Close them. Dec 16, 2021 at 3:18
  • I like the solution. Unfortunately we're the child company of an enterprise where browser extensions are tightly restricted and managed by the organization. Dec 16, 2021 at 5:42

In our department we wanted to increase security awareness. One point of attention was that laptops may only be left unattended with a locked screen.

If you found an unattended laptop with an unlocked screen, you were allowed to send a mail from this person's Outlook to all department members, stating "Tomorrow I will bring cake for everyone". And then lock that laptop (Windows-L key).

This has proven to be very effective. For one or two persons it was difficult to make a habit out of locking their screens when leaving the laptop, but after a few weeks it was difficult to find unlocked, unattended laptops.

People were motivated to lock their own laptop as well as to watch out for unlocked laptops of colleagues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .