The Myth of the “Simple Change”

The Most Deceptive Label in Deployment

In the lexicon of Salesforce project management, there is no phrase more terrifying to a seasoned QA engineer than:

“Don't worry, it’s just a simple change.”

It is the prelude to every major outage. It is the justification for skipping regression testing. It is the reason why a "quick fix" deployed on Friday afternoon leaves the Support team drowning in tickets on Monday morning.

We need to be clear about the reality of the platform we work on: There is no such thing as a simple change in Salesforce.

There are only changes with known impact, and changes with unknown impact.

“Simple” is just a code word for "we haven't mapped the dependencies yet."

Why Changes Feel Small

Salesforce is brilliant at hiding complexity. The UI is designed to make you feel powerful and agile.

• You add a field with three clicks.
• You tweak a Flow connector with a drag-and-drop motion.
• You add a value to a Global Picklist in seconds.

There is no code to write. There are no compilation errors to scream at you. There is no heavy deployment drama. Because the act of making the change is low-effort, we subconsciously assume the risk of the change is low-impact.

But Salesforce is metadata-driven. Every component is woven into a massive, invisible spiderweb. When you tug on a thread in the Object Manager, you have no idea what is shaking in the Integration layer unless you look.

The Classic Failure: The "Just a Picklist" Update

Let’s look at the classic example that has burned every Admin at least once.

The Request: "Please add the value 'On Hold' to the Opportunity Stage picklist."

The "Simple" Change: The Admin adds the value.
The "Simple" Test: The QA logs in, opens an Opportunity, changes the Stage to 'On Hold', and saves. Success. The field updates. The UI looks good. Deploy it.

The Production Reality:

1. Flow Failure: An After-Save Flow has a decision element that routes logic based on specific Stages. It doesn't have a path for 'On Hold', so it defaults to a 'Fallthrough' path that sends an email to the CEO.
2. Integration Rejection: The ERP system listening for Opportunity updates has a hard-coded mapping. It receives 'On Hold', doesn't recognize it, and throws a 400 Bad Request error. The sync stops.
3. Reporting Gap: The Executive Dashboard filters Opportunities where Stage is "Closed Won" or "Negotiation". The new 'On Hold' records vanish from the pipeline entirely.

Nothing "broke" in the traditional sense. The system behaved exactly as configured. The failure wasn't in the feature; it was in the dependency map.

Why Impact Analysis Is Skipped

Why do we keep falling for this? Because impact analysis is invisible work.

Checking dependencies doesn't produce a shiny demo. It doesn't move a card across the Kanban board. It feels like "slowing down."

• It requires searching the metadata.
• It requires reading through ugly legacy Flow logic.
• It requires asking the Integration Architect if the middleware can handle the change.

But skipping this work doesn't save time. It just transfers the cost from the Development phase to the Production phase—where the currency is user trust, and the exchange rate is terrible.

The QA Responsibility

As testers, we are the last line of defense against the "Simple Change" myth. We must be the annoying voice in the room that asks the uncomfortable questions.

Salesforce won't warn you that your new Validation Rule blocks the API user. It will just execute the logic.

QA Takeaways

• Ask "Where else?": When a field changes, asking "Where is this referenced?" is mandatory. Use the 'Where is this used?' button, but don't trust it blindly (it often misses Apex references or dynamic Flow lookups).
• Test the Consumer, Not Just the Producer: Don't just test that you can save the data. Test the downstream systems that consume the data (Reports, Integrations, Scheduled Flows).
• Challenge the Classification: If a ticket is labeled "Low Risk," ask for the dependency map. If one doesn't exist, the risk is "Unknown," not "Low."
• Reclassify Your Mindset: Stop classifying changes as Simple vs. Complex. Classify them as Mapped vs. Unmapped. Only mapped changes are safe.

The Uncomfortable Truth

Most Salesforce incidents are not caused by complex bugs or platform limitations. They are caused by the sentence:

“We didn’t realize this was connected.”

In Salesforce, "simple" is usually just a synonym for unexplored complexity.

What is the "simplest" change that ever caused a disaster in your Org? Share your war stories below.