04.04.03 — Failure Modes in Integrated Environments
Lesson goal
This lesson explains how QA should test and document integration failures in Salesforce environments where multiple systems interact asynchronously.
After completing this lesson, you should be able to:
- identify common integration failure modes
- design test cases for partial and asynchronous failures
- verify compensating logic and recovery paths
- validate error logging and user-facing feedback
- document failure behavior in a predictable, supportable way
This lesson closes the Integration Resilience part of Module 4.
The problem: partial failure is normal
In real-world Salesforce integrations, clean success or clean failure is rare.
Much more often, systems fail partially:
- Salesforce succeeds, external system fails
- external system succeeds, Salesforce fails
- data is created, but confirmation is lost
- logic is rejected after a technically successful call
These scenarios create inconsistent system states that:
- cannot be rolled back automatically
- require compensating logic
- often need human intervention
QA must assume that partial failure is the default, not the exception.
How integrations fail in practice
Integration failures usually fall into three categories:
- full technical failure
- partial or asynchronous failure
- business logic rejection
Each must be tested deliberately.
Full integration failure: system unavailable
This is the simplest failure mode: the external system cannot be reached or rejects the connection entirely.
Full failure test case
- Action: Trigger an integration while simulating an outage
(invalid endpoint, expired token, blocked network) - Expected result:
- Salesforce responds within reasonable time
- synchronous transactions are rolled back
- asynchronous processes mark the record as Fatal Error
- a detailed technical error is logged (HTTP code, message)
QA must verify that:
- no records are left in an ambiguous state
- failures are visible to support teams
- retry logic does not loop indefinitely
Partial system outage: asynchronous inconsistency
Partial failures are the most dangerous.
They occur when one system commits data, but the confirmation or follow-up step fails.
Example scenario
- Salesforce sends a request to create an Order in ERP
- ERP successfully creates the Order
- Salesforce never receives the External ID due to timeout or malformed response
Partial failure test case
- Action: Trigger the integration but return an incomplete response
- Expected result:
- Salesforce record remains in Pending or Inconsistent state
- no automatic rollback is attempted
- a notification is sent to integration support
- record is clearly flagged for manual reconciliation
QA must ensure:
- the system acknowledges inconsistency explicitly
- no duplicate retry blindly recreates the external record
- operators know exactly what failed and why
Business logic failure: data rejected
This failure occurs when:
- the integration works technically
- the payload is delivered
- the external system rejects the data based on its own rules
This is the most subtle and common failure mode.
Business rejection test case
- Action: Send data that violates external business rules
(e.g. invalid code, missing reference, unsupported value) - Expected result:
- external system returns a structured error
- Salesforce captures the error details
- user or admin sees a clear, actionable message
Example:
ERP rejected record: Customer Tier 'Z-Invalid' does not exist.
QA must verify that:
- technical errors are translated into business-readable messages
- users are not forced to guess what went wrong
- retry is blocked until data is corrected
Practical QA strategies for failure testing
Document the failure playbook
For every integration endpoint, QA should help define a Failure Playbook.
This includes:
- failure classification
- automated system behavior
- required human action
Example structure:
- transient failures → automatic retry
- authentication failures → fatal error + admin action
- data rejection → user correction + re-sync
Without this documentation, production support becomes reactive and chaotic.
Null and empty payload testing
Simple tests often expose critical weaknesses.
QA should test:
- Salesforce sending null or empty optional fields
- external system returning null for expected fields
Expected behavior:
- no system crash
- no unhandled exceptions
- controlled handling of missing values
Null-handling failures often surface only in production.
Summary: failure is part of the design
In integrated Salesforce environments, failure is not an edge case.
It is a core behavior that must be tested, documented, and understood.
From a QA perspective:
- full failures must fail cleanly
- partial failures must be visible and recoverable
- business rejections must be understandable
- no failure should leave the system in a silent or ambiguous state
By deliberately testing failure modes, QA ensures integration resilience, operational clarity, and long-term system trust.
An integration is not defined by how it succeeds,
but by how predictably it fails.