Building a Product QA Framework Across Salsify and Downstream Platforms

The product existed. The SKU existed. The page existed.

And somehow, according to QA, absolutely none of them agreed with each other.

Welcome to product-data integration.

If you have ever worked with a PIM, a CMS, a storefront, and a few scheduled imports in between, you already know where this is going. One system says the product is correct. Another says it is missing. The website says something completely different. Then somebody opens a spreadsheet and starts checking rows manually.

I decided that was a terrible way to spend an afternoon.

The problem

When product data moves through several systems, a successful import does not automatically mean the final customer-facing result is correct. Fields can be missing, mapped differently, attached to the wrong variant, or simply stale downstream.

I needed a repeatable way to compare source product data with what actually made it to the rendered product page.

Salsify
   ↓
Product export
   ↓
Website platform
   ↓
Rendered product detail page

The approach

I built a PowerShell-based QA framework that treats the process as a pipeline instead of one giant script. Each step has one job: load the targets, load the source data, match products, inspect the destination, validate fields, and generate a report.

The destination layer is intentionally platform-neutral. I care about the final rendered result more than which CMS produced it.

QA Spreadsheet
      ↓
Salsify Export
      ↓
Product Matching
      ↓
Destination Loader
      ↓
Validation Engine
      ↓
Excel Report

Matching is its own problem

A failed comparison and a failed match are not the same thing. URLs change. Variants share parent pages. SKUs can live in structured data instead of visible content.

So the framework identifies the product first, then validates it. If the match is uncertain, that becomes an explicit result instead of a misleading pass or fail.

Results people can actually use

The final Excel workbook includes summary, product-level, field-level, and unmatched-product views. Developers can dig into the exact mismatch while someone else can start with the overall health of the import.

• PASS — expected and actual values match.
• FAIL — values differ, the page cannot be loaded, or the product cannot be matched.
• WARNING — something is missing but may not be a critical failure.
• SKIPPED — the source does not contain a value worth comparing.

Why PowerShell?

Because it fit the job. The workflow involved files, JSON, URLs, comparisons, Windows-based tooling, and Excel output. PowerShell handled all of that without needing a larger application stack.

The interesting engineering decision was not the language. It was keeping the pieces modular enough that the framework could grow.

What I took away from it

The biggest lesson was simple: validate the thing the user actually receives.

A green import job is nice. A correct final result is better.

That idea applies well beyond product data. Any workflow that crosses multiple systems benefits from checking the output at the point where people or downstream services actually consume it.