The Most Dangerous Sentence in Salesforce Testing

The Sentence That Should Stop the Meeting

There is one sentence that should immediately raise a red flag in any Salesforce project. It sounds harmless. It sounds efficient. It sounds like the voice of experience.

“We don’t need to test this, it’s just standard Salesforce.”

You hear it during refinement. You hear it during defect triage. You hear it when the timeline is tight.

And that sentence has probably caused more production incidents than any complex Apex class ever written.

“Standard” Does Not Mean “Untouchable”

Yes, Salesforce provides robust standard objects (Leads, Opportunities, Cases).
Yes, Salesforce provides standard automation engines (Approval Processes, Assignment Rules).
Yes, Salesforce provides standard security models (Roles, Profiles).

But the moment you configure it, the moment you connect it to something else, or the moment you depend on it for a specific business outcome—it stops being "just standard."

It becomes part of your system. And your system is definitely not standard.

Where This Sentence Usually Appears

This fallacy usually hides in very specific areas of the platform:

• Lead Conversion: "The conversion process is native, Salesforce handles the mapping."
• Approval Locking: "The record locks automatically, we don't need to check that."
• Sharing Rules: "It’s declarative configuration, it just works."
• Standard Fields: "We’re just using the standard 'Status' field."

Every time, the logic is the same: Someone else (Salesforce) already tested this for us.

And that is true—for Salesforce, not for your implementation.

The Hidden Cost of Trust

Salesforce absolutely guarantees how Lead Conversion works conceptually.
What Salesforce does not guarantee is that your custom Validation Rule on the Contact object won't block the conversion because the Lead didn't have a required phone number.

Salesforce guarantees how Approval Processes lock records.
What Salesforce does not guarantee is that your nightly integration job won't crash because it tried to update that locked record while the approver was asleep.

The platform is stable. Your assumptions are not.

A Quick Reality Check

If you think a feature is "safe to ignore" because it's standard, run this checklist. If any of the following exist in your Org, you are no longer testing Salesforce standard functionality:

• [ ] Custom Fields on standard objects.
• [ ] Validation Rules.
• [ ] Record-Triggered Flows.
• [ ] Apex Triggers (even from managed packages).
• [ ] Integrations.
• [ ] Record Types.
• [ ] Data volume > 10,000 records.

If you checked even one box, you are testing a distributed system with opinions.

The "Standard" Trap in QA Thinking

The sentence is dangerous because it quietly removes curiosity.

If something is "standard," we stop asking:

• What if?
• What happens when…?
• Who else is affected?

Instead, we replace critical thinking with blind trust. And Salesforce punishes blind trust very politely—usually about three days after go-live, when the data is already corrupt.

The Better Sentence

We need to reframe how we talk about platform features. Replace the dangerous sentence with this one:

“Salesforce guarantees the mechanism. We test the consequences.”

That single shift changes everything. It acknowledges the reliability of the platform while accepting responsibility for the implementation.

QA Takeaways

• Test the Handoffs: Don't test if Lead Conversion works. Test if your data survives the conversion and passes the validation rules on the target objects.
• Test the Lock: Don't test if the Approval Process locks the record. Test what fails when the record is locked (e.g., automation, background jobs).
• Test the Side Effects: Standard features often have side effects (emails sent, tasks created). Verify that these standard side effects don't collide with your custom automation.

Final Thought

Salesforce is incredibly reliable. That’s exactly why it’s dangerous to underestimate it.

The platform will always do something. QA’s job is to make sure it’s the right something.

And “standard” has never been a valid test case.

What is the most "standard" feature that has ever broken your custom build?