How many required fields should a new SKU have?

Few enough that a merchant can create one in a single sitting, and no fewer than what makes the record identifiable, classifiable and routable. In most catalogs that lands between eight and fifteen fields. If your list is forty, you have confused what makes a SKU valid with what makes it sellable, and those are different gates.

Should required fields differ by category?

Yes, and this is the main argument for classifying a product first. A core set applies to everything, then the category adds its own. Wire size matters for fasteners and never for paint. A flat, universal required-field list is either too thin for the complicated categories or too heavy for the simple ones.

When is free text acceptable?

Product name, long description and keyword fields, plus a genuine notes field that no downstream system reads. Everything else should be typed, bounded or drawn from a controlled list. Free text is where reporting goes to die, because two people will always spell the same value three ways.

Do we need a rules engine, or can validation live in the PIM?

Simple field-level validation belongs in the PIM. Multi-condition logic that reads several attributes to decide an outcome usually does not, because most PIM rule builders become unreadable past a handful of conditions. If your logic has grown into a decision table, move it somewhere designed to hold one.

What happens to the products that were created before any of this existed?

Leave them alone at first. Apply the rules to new creation, then measure the legacy catalog against the same rules as a defect report and work it down by priority. Retrofitting governance and cleaning history at the same time stalls both.

What data governance rules belong at SKU creation?

Enforce the smallest set of fields that makes a SKU valid to exist, type every field so it can only accept what it is meant to hold, and defer conditional or channel-specific requirements to a later stage. Creation-time governance is a trade: too many gates and the catalog team routes around them, too few and every downstream system inherits errors it cannot detect.

The trade-off you are making

Every gate at SKU creation buys accuracy and costs time. That is the design problem, and the answer is specific to your catalog: how fast the assortment turns over, and how much damage bad data does downstream.

A catalog onboarding two hundred SKUs a week from a dozen suppliers cannot afford a forty-field creation form; the team will create placeholder records to get past it, and placeholders are worse than gaps because they look populated. A catalog adding twelve highly configured industrial SKUs a month can afford a great deal of rigor, because the cost of a wrong specification is a returned pallet.

Get this backwards and you will see the symptom before you see the cause: fields populated with TBD, ., N/A, 9999, or the supplier’s name repeated into four different attributes. Those are not data-entry errors. They are people telling you your gate is in the wrong place.

Rule of thumb. If a required field is regularly filled with a junk value, either it should not be required at creation, or nobody entering it has the information yet. Both are fixable. Neither is fixed by training.

Required fields: the barebones SKU

Start from a question with an unambiguous answer: what does this record need in order to exist as a distinct, findable, orderable thing? Not to sell well. To exist.

For most catalogs that resolves to five groups:

Identity. SKU or item number, supplier part number, GTIN or UPC where the category has one.
Classification. The single master taxonomy node. This one field decides which further attributes are required, which workflow the record enters, and who owns it, so it cannot be deferred.
Relationship. Parent product or variant group, if the record is a variant. Retrofitting variant structure after publication is one of the more expensive corrections in catalog work.
Commercial basics. Supplier or vendor of record, cost or price depending on which system is authoritative, and unit of measure.
Naming. A product name that follows your naming convention rather than the supplier’s marketing.

Everything else counts as enrichment: imagery, long copy, dimensional data, compliance documents, channel-specific overrides. It belongs to a later stage with its own gate. Mixing enrichment requirements into creation requirements is the most common way a governance program dies in its first quarter.

Type every field you can

Wherever the platform allows it, configure a field to accept only what it means. A date field that accepts Spring 2027 is a text field wearing a costume.

The decisions worth making deliberately:

Single-select versus multi-select. Multi-select is seductive and hard to reverse. Ask whether a single product can truly have two of these values simultaneously. Material often can. Country of origin usually cannot.
Decimal versus integer. Integers where fractional values are meaningless, and a defined precision where they are not. Undeclared precision is how the same weight becomes 2.5 and 2.50 and 2.500 across three systems.
Numeric with unit versus text. 12 in in a text field is not a length. Store the number and the unit separately, or store a normalized base unit and display the conversion. Filters, sorting and any conversion logic depend on this.
Hierarchical versus flat lists. A colour family that rolls up to a colour name is a hierarchy and should be modeled as one, so that “blue” on the site can mean sixty stocked shades.
Bounded lists versus open entry. Any value a customer will ever filter on must come from a controlled vocabulary. No exceptions survive contact with a facet.

Exception requests will arrive, and they will be marked urgent. Ask what the exception is for. Most resolve into either a missing attribute or a value that belongs in a different field. A genuine exception is rare enough that granting it should feel notable.

Enforce downstream limits at the point of entry

Every system you publish to has constraints: character limits on names, allowed character sets, required formats for identifiers, maximum value counts on a facet. Find them, write them down, and enforce them where the data is typed rather than where it is rejected.

The alternative is a truncation that nobody sees until a customer does. A 255-character name field feeding a marketplace that accepts 150 does not error. It cuts the sentence, usually mid-word, usually on the products that needed the description most.

This mapping is unglamorous and it dates quickly, so treat it as a maintained artifact rather than a one-time discovery. Every new sales channel adds a column to it.

Rules engines: when field validation is not enough

Field-level validation answers “is this value allowed here”. A rules engine answers “given everything this record now contains, what should be true of it”. Those are different questions, and the second one is where categorization, routing and derived attributes live.

Typical work for a rules engine:

Assign or verify classification from supplier attributes, so categorization is reproducible rather than a judgment call made twice differently.
Derive attributes that are functions of other attributes, rather than asking a human to compute and re-key them.
Decide workflow routing: which review queue, which enrichment path, which approver.
Flag combinations that are individually valid and jointly impossible.

If your PIM has a capable native rules layer, use it. If it does not, the logic can live in the search engine’s indexing pipeline, in the ETL layer between systems, or in a dedicated decision-engine service. That category covers open-source DMN-based engines and hosted rule services. The specific product matters far less than getting the logic out of tribal knowledge and into something reviewable and version-controlled.

There is a diagnostic buried in this. When data fails to flow cleanly from one point to the next, the cause is almost always missing or malformed data rather than a broken integration. A rules engine makes that failure explicit at the moment of creation instead of at 3 a.m. in a feed job.

What creation-time governance cannot do

It cannot make data accurate. A stainless steel bowl entered as aluminium passes every gate described here, because the value is well-typed, on the controlled list and populated. Creation-time rules catch structural failures: missing, malformed, contradictory. Accuracy is caught later, by defect reporting run against the whole catalog, and by sampling against the source.

It also cannot decide when a product is ready for a specific channel, which is a different threshold applied at a different moment. That is the job of validation in the publishing path and of completeness scoring.

Build the creation gate to make records structurally sound and get them moving. Build the later gates to decide whether they are good enough to be seen.