When a Bug Is “By Design”: The Ultimate Conversation Stopper
The Most Frustrating Phrase in QA
In the lifecycle of a Salesforce ticket, there is a specific moment where the investigation hits a brick wall. You report a defect. You describe the behavior. You attach the screenshots.
And the ticket comes back with the status Rejected and the comment:
“This is by design.”
Or its cousin, the acronym WAD (Works As Designed).
It sounds authoritative. It sounds final. It implies that the weird behavior you just witnessed was the result of a thoughtful, architectural decision made by wise stakeholders months ago.
But in Salesforce projects, "This is by design" is rarely a reference to a specification document. It is usually a shield.
Why This Phrase Appears
Salesforce behavior is often non-obvious, metadata-driven, and context-sensitive. When something behaves unexpectedly—like a field disappearing or a record locking—it is easy to assume the platform is doing it "on purpose."
When a Developer or Admin says "It's by design," they often mean:
- "I don't know why it does that, but I didn't write code to stop it."
- "That's standard Salesforce behavior (and I can't change it)."
- "Nobody told me it shouldn't do that."
The conversation ends. The ticket is closed. But the risk remains.
The Hidden Assumption
The danger of accepting "by design" without question is that it conflates outcome with intent.
Just because the system consistently does X, does not mean the business intended X.
In Salesforce, unintended designs emerge constantly.
- A Validation Rule written for Sales Ops inadvertently blocks Customer Support. Is that by design?
- A Flow updates a field, which triggers a legacy Workflow, which sends an email to the client. Is that by design?
Technically, the system is executing its logic perfectly. But the design is flawed. "By design" often means: "Nobody checked the requirement, and nobody modeled the edge case."
Salesforce Enables This Escape
It is easy to blame the platform. Salesforce has thousands of default behaviors, implicit logic paths, and undocumented interactions.
- "Oh, Opportunity Products are locked because the Opportunity is Closed Won. That's standard."
- "You can't change the Record Type because of the conversion process. That's standard."
Sometimes, this is valid. Salesforce has hard limits.
Often, it is not. It is simply a configured behavior that we have forgotten we configured.
The QA Counter-Question
As a tester, you cannot accept "Works As Designed" as a test result. You must treat it as a claim that requires evidence.
Whenever you hear this phrase, you must ask four questions:
- Which design? (Is this a Salesforce standard feature, or custom logic?)
- Whose design? (Did the Product Owner request this, or did the Developer assume it?)
- Where is it documented? (Show me the User Story or the Functional Spec.)
- Who accepted the risk? (Does the business know this happens?)
If those answers don’t exist, there is no design. There is only an accidental outcome that we are trying to rationalize.
A Common Example: The "Read-Only" Trap
Let’s look at a classic scenario.
The Bug: A user complains that they cannot edit the "Delivery Date" on an Order record.
The Dev Response: "That's by design. The record is locked."
This explains how (the record is locked) but not why.
The QA Interrogation:
- "Which automation locks it?" -> It's an Approval Process.
- "Under what condition?" -> When Status is 'Submitted'.
- "For which roles?" -> Everyone, apparently.
- "Does the Logistics Manager need to update the Date after submission?" -> Yes, actually, that's their whole job.
The behavior was "by design" in the technical sense—the Approval Process was configured to lock the record. But the design failed the business process. By challenging the justification, QA uncovered a critical process gap.
The Real Danger
Design justification stops investigation. It allows teams to sleepwalk into Production issues because they assume someone, somewhere, made a decision.
Salesforce does not protect you from bad assumptions, partial logic, or accidental behavior. It executes exactly what you tell it to execute, even if what you told it to do is nonsense.
QA Takeaways
- Demystify "Standard": Don't let people use "Standard Salesforce" as a magic wand. Verify if it really is a platform constraint or just a setting.
- Demand the Source: If a behavior is "WAD," link it to a requirement. If there is no requirement, create a new User Story to define the expected behavior.
- Validate the User Experience: Even if something is technically "by design," if it confuses the user, it is a usability defect. Flag it.
"By design" is an explanation. It is never a validation.
What is the most ridiculous "feature" you've seen that turned out to be a bug "by design"?