One Checkbox in Production: How Salesforce Orgs Break Quietly

Friday, 16:47. Sales needs the Region field filled on every new Account, starting now, because a report for the board goes out on Monday. The admin opens Setup in production, adds a validation rule, tests it on one record, and goes home. It takes four minutes. It is also the most expensive thing anyone in the company does that week.

How the weekend goes

The webshop creates Accounts in Salesforce through an integration. The integration does not send Region, because until Friday nobody needed it to. From 16:47 on, every new customer is rejected by the validation rule. The integration logs the error where integration errors always go: a table nobody opens on a weekend.

Monday, 9:10. Sales asks why there are no new orders since Friday. The integration team checks their side: it is up. The release team checks theirs: the last deployment was on Wednesday and nothing in it touched Accounts. Somebody suspects Salesforce itself and opens a support case. Around 11:30 someone finally reads an error message closely enough to see the rule's name.

The rule is deactivated in thirty seconds. Finding it took a morning. Replaying three days of rejected customers, and explaining to the ones who got no order confirmation, takes the rest of the week.

Nobody in this story was careless. The request was real, the change was correct for what it was asked to do, and the admin even tested it. What was missing was not skill. It was that nobody else knew the change had happened.

Small changes, big blast radius

Salesforce makes production easy to change on purpose. That is its strength, and it means a single admin can do a lot with one Save button:

• A validation rule or a required field. Correct for users in the UI, fatal for every integration and import that did not get the memo.
• A new version of a flow. "Just a small fix" activated directly in production can start emailing customers, updating records it never touched before, or failing on a record type nobody tested.
• Modify All Data for an hour. Granted to a profile or permission set to debug something urgent. The bug gets fixed. The permission stays, for everyone with that profile, for months.
• Sharing and login settings. One changed organization-wide default can make every salary, contract or health record visible to the whole company. One changed session or IP setting can lock out a team, or quietly let everyone in.
• A connected app policy. Switching to "All users may self-authorize" to unblock one integration opens the same door for every app user.
• A deleted field or a deactivated picklist value. Tidy in Setup, broken in the reports, dashboards and external systems that still expected it.

Every one of these takes under a minute and looks harmless on the screen where it is made. The damage happens somewhere else, to someone else, usually later.

The second incident: the next release

Even a good manual change causes trouble if it stays a secret. The fix made directly in production is not in your repository. The next release, built from the repository, either overwrites it and brings the original problem back, or fails on a difference nobody can explain. Either way the team spends a day rediscovering something one person already knew.

This is how orgs drift. Not through one big decision, but through dozens of reasonable, urgent, undocumented changes, each made by someone who meant to tell the team and then had a meeting.

Why it is always found late

Your deployments have guardrails: pull requests, reviews, test runs, an approval before production. A manual change in Setup goes around all of them. And although Salesforce records every one of them in the Setup Audit Trail, nobody reads the trail until something is already broken. It is used for forensics, not for awareness.

That turns the real cost of an incident into time to detect. The fix is almost always quick. The hours go into the question everyone asks first: what changed? If the answer arrives on Monday at 11:30, it is a crisis. If it arrives on Friday at 17:45, it is a two-line conversation.

What changes when the team can see it

Visibility is not about catching anyone. In practice it changes behaviour in small, useful ways:

• The person who made the change replies in the thread: "that was me, the board report needs it, I'll tell the integration team." The problem is solved before it exists.
• A second pair of eyes spots "Modify All Data" on a profile the same afternoon, not at the next yearly access review.
• The hotfix gets copied into the repository because everyone saw it go in, so the next release does not undo it.
• When an auditor asks how you monitor changes to production, you show them a channel history instead of a promise.

And there is a quieter effect: people make fewer unannounced changes when they know the team will see them anyway. Not out of fear, but because announcing it first becomes the obvious thing to do.

How Org Radar does it

This is the problem Org Radar exists for. It is a native Salesforce app that reads the Setup Audit Trail for you and sends the changes made by the admins you choose to track to Slack, Microsoft Teams or Google Chat, on the schedule you pick.

• Readable, not raw. Entries of one operation are grouped into one numbered item, so ten lines of a connected app setup read as one change.
• The dangerous ones stand out. Users, permissions and security settings are marked by severity, and each channel can have its own.
• Only people, not pipelines. Your CI/CD user does not flood the channel. You track the humans with production access.
• Hard to switch off quietly. Changes to who is tracked are announced on every channel, and nobody can stop tracking themselves. When nothing changed, an occasional heartbeat says so, so silence never hides a broken job.
• Safe to post. Tokens and secrets quoted in audit entries are masked before anything leaves the org.
• Inside your org. No server of ours in the middle: messages go from your Salesforce straight to your own chat.

Changes arrive with a delay of about an hour, so a long deployment is never cut in half. In the Friday story, that means the team would have seen the validation rule before most of them left for the weekend.

More on why the Setup Audit Trail goes unread, and what that costs: who changed production?

In short

Manual changes in production are not the problem. They are often the fastest correct answer to a real request. The problem is changes nobody else knows about. Put them where your team already talks, and most incidents turn into a short message on Friday instead of a long Monday.