Data · Integrations · Debugging

Two Fields Named "Product Type" Walk Into an Importer

A brand's product filters went sideways after an import. The cause wasn't one bug. It was three, plus a naming collision, plus a mapping that had never worked a single day in its life.

The filters went missing

On one brand's product listing pages, shoppers can narrow results with category filters, like picking a type of bedding. If you're shopping for one specific kind of thing, filtering by that kind of thing is the whole point.

After a bad import from Salsify, those filters were broken or missing. So I went digging, expecting one bug.

I found three. Then I found a fourth problem that wasn't even a bug. It was a naming coincidence.

Bug 1: The map only had four roads

The importer uses an attribute map to decide which Salsify field feeds which Sitecore filter. This brand's map had exactly four entries.

The brand has more than 20 category-specific filter groups.

So for most of the filters, nothing told the importer where the values should go. You can't really blame a script for not delivering mail to an address nobody gave it.

Bug 2: A mapping to nowhere

One of those four mappings pointed to a filter group by name.

There was no group with that name. The real groups had longer, slightly different names. Close. Not the same.

Which means that mapping has never worked. Not broken by the import. Never worked, ever. It's hard to break something that never worked, but it's very easy to never notice.

Bug 3: Bedding, Bedding & Substrate, and Décor's evil twin

The Product Type filter had duplicates and near-duplicates. "Bedding" next to "Bedding & Substrate." A "Décor & Dishes" with a mangled accent sitting next to plain "Decor."

The cause was in how the original importer matched values. It looked up existing values by a single key. When the text coming from Salsify changed even slightly, the importer didn't recognize the match and created a brand-new value instead of reusing the old one.

Do that enough times and your filter list starts to look like a family reunion where nobody's sure who's related.

Bedding
Bedding & Substrate
Décor & Dishes  (with a corrupted accent)
Decor

The naming collision

An earlier repair attempt made things worse and got rolled back. It took very specific values like "Wood Bedding," "Glass Habitat," and "Water Care" and dumped them into the main Product Type filter, which is supposed to hold broad categories.

Here's why. Salsify has a field literally named "Product Type" that only exists on child product rows. Sitecore also has a filter named "Product Type," but it's fed by a different parent-level field.

Same name. Completely different meaning. Match on the name, and you send every value to the wrong place with total confidence.

Salsify child field   "Product Type"   → Wood Bedding, Glass Habitat...
Sitecore filter       "Product Type"   ← fed by a parent-level category field

Same name. Different data. Do not match on name.

Rolling back is a skill too

When a fix makes things worse, the right move is to undo it quickly and figure out why, not to pile another fix on top.

Rollbacks are underrated. They don't feel like progress. They are.

What I took away from it

  • Names lie. Two fields with the same name can mean completely different things.
  • Check that a mapping's target actually exists. Config that points at nothing fails silently.
  • Matching on one key is fragile when the source text can change.
  • When the symptom is one broken filter, look for more than one cause.
  • Roll back fast when a fix is wrong.