04.04.02 — Testing Data Consistency Across Systems

Lesson goal

This lesson explains how QA validates data consistency in integrated Salesforce environments.

After completing this lesson, you should be able to:

• understand why latency is unavoidable in integrations
• test whether synchronization delays are acceptable to the business
• verify retry and recovery mechanisms
• detect data overwrite and conflict scenarios
• validate system-of-record (SOR) rules across systems

This lesson closes the Performance and Integration Risk section of Module 4.

The problem: the latency gap

In integrated systems, data consistency means that the same logical record:

• exists in Salesforce
• exists in one or more external systems (ERP, billing, finance)
• represents the same business truth at a given point in time

The core challenge is the latency gap:

the time between when data changes in one system and when that change appears in another.

Latency is normal.
Uncontrolled latency is dangerous.

If not tested, latency leads to:

• conflicting reports
• incorrect business decisions
• double processing
• broken downstream automation

QA must treat latency as a first-class test dimension.

How consistency fails in real systems

Data consistency issues usually appear in three forms:

1. excessive delay
2. failed synchronization and retries
3. conflicting updates across systems

Each requires a different testing strategy.

Latency testing: measuring the delay

Latency testing verifies whether synchronization delay stays within business-acceptable limits.

End-to-end latency test

• Action: Trigger an integration event in Salesforce
  (e.g. set Integration_Flag__c = TRUE)
• Measurement:
• record timestamp T0 in Salesforce
• record timestamp T1 in the external system
• Expected result:
  (T1 − T0) is less than the defined SLA (for example, 5 minutes)

Latency is not a defect by default.
Latency exceeding SLA is.

Bulk latency behavior

Latency must also be tested under load.

• Action: Trigger synchronization for 50–100 records
• Expected result:
  Latency increases predictably but does not degrade exponentially

If bulk operations stall or queue indefinitely, scalability is broken.

Retry mechanisms: self-healing integrations

Well-designed integrations assume failure.

Temporary issues include:

• external system downtime
• network instability
• transient HTTP errors (500, timeout)

QA must verify that the integration recovers automatically.

Retry behavior test

• Action: Trigger integration while simulating external failure
• Verification: Monitor integration logs or status fields
• Expected result:
• initial failure is logged
• system retries according to schedule (e.g. 5 / 10 / 30 minutes)
• successful retry results in consistent data
• final status is marked as Success

Fatal failure handling

After maximum retries:

• the system must stop retrying
• a human must be notified

QA must verify:

• alert delivery (email, Slack, ticket)
• clear failure state for manual resolution

Silent failure is unacceptable.

Synchronization conflicts: system of record

The most complex scenario is simultaneous updates.

When two systems update the same record at the same time, the integration must respect a defined System of Record (SOR).

Conflict testing example

Assume:

• Salesforce is SOR for Account.Name
• ERP is SOR for Billing_Address

Action:

• Update Account.Name in Salesforce
• Update Billing_Address in ERP at the same time

Expected result:

• Salesforce value wins for Name
• ERP value wins for Billing_Address
• neither system overwrites fields it does not own

If data oscillates or overwrites unpredictably, trust is lost.

Practical QA patterns for consistency testing

Integration status field

Every integrated object should expose a clear integration state.

Typical values include:

• Pending
• Processing
• Success
• Fatal Error

QA uses this field to:

• track lifecycle progression
• detect stuck records
• validate retries and recovery

Without a status field, integration testing becomes guesswork.

Idempotency testing

Idempotency ensures that sending the same request twice does not create duplicates.

Idempotency test case

• Action: Trigger an integration successfully
• Immediately trigger the same request again
• Expected result:
• no duplicate records in the external system
• system recognizes the request using a unique key (External ID)

This is critical for:

• financial systems
• order creation
• invoicing

Failure here causes real business damage.

Summary: consistency equals trust

Data consistency testing goes beyond functional validation.

From a QA perspective, it ensures that:

• latency stays within business limits
• failures recover automatically
• conflicts resolve predictably
• systems do not drift apart over time

By testing latency, retries, idempotency, and system-of-record rules, QA ensures Salesforce and external systems behave as a single, reliable enterprise platform.

An integration that works once is not complete.
An integration that stays consistent over time is.