Prepare an approved product master before selecting a Salla theme or loading the catalogue in bulk. Names and images are only part of the work. You need to know what is actually purchasable, how price, stock and imagery vary between options, and who approves each fact. These decisions determine whether customers order the right item and employees can fulfil it.
This is different from presenting a readable specification table in a printed catalogue. In a store, an option may change the record being sold. Make data preparation explicit in the Salla store development scope: will the merchant supply implementation-ready information, or does it need organisation and approval first?
Separate the product family from the sellable combination
A product is the family a shopper recognises, such as a particular shirt design. A variant is the combination they order, such as navy in medium. Do not assume every possible colour-and-size combination exists. Creating a neat grid is not a reason to offer something the warehouse does not carry.
Salla documents native product options and quantity management. Check those capabilities before proposing custom development. Salla's physical-product guide.
Maintain a clear parent record and identifiable sellable combinations. If everything sits in one file, the relationships should survive sorting and filtering. Merged cells, visual spacing or row order alone should not be the only explanation of which variant belongs to which parent.
Build the master around accountable facts
| Data group | Information to approve | Appropriate owner |
|---|---|---|
| Identity | Stable code, name and parent relationship | Catalogue owner |
| Commercial | Price, currency and promotion period | Commercial approver |
| Inventory | Quantity, source and timestamp | Stock owner |
| Selection | Option names and available values | Product and operations owners |
| Description | Dimensions, material and included items | Product information owner |
| Media | Approved files and option mapping | Asset and content owner |
Record when stock and pricing were approved. A file received yesterday is not necessarily a verified statement of today's inventory. Separate an unknown value from a genuine zero. Put unresolved questions in a review register rather than inserting a convenient placeholder into a commercial field.
Product catalogue design and Arabic adaptation can help organise approved specifications and terminology. Clarify whether the commissioned work includes data structuring, editing and translation. Page design does not automatically include warehouse counting or the verification of specifications the merchant has not supplied.
Agree validation rules before import
Use one approved label for recurring values. Do not alternate between “navy” and “dark blue” within the same product without a reason. Preserve manufacturer codes and model references as approved, and test identifiers with leading zeros so spreadsheet processing does not silently change them. An image filename should not be the only product identifier.
Review unique codes, consistent units, accessible asset references, missing prices and repeated options. Classify records as ready, held for review or deliberately excluded. A row's presence in the master does not authorise its publication.
Obtain the current import format for the actual route being used, then map the master to it. Your internal data model is not automatically a valid platform template. Field names and option representation may differ between transfer tools. Test an update as well as a new import: a second upload should have a known effect, not an assumed one.
Keep a separate change record after approval. If the merchant alters a price while the implementer is preparing the upload, someone must decide which version is authoritative. The simplest process is often a named approval checkpoint followed by a controlled list of subsequent changes, rather than several files all labelled “final.”
Worked hypothetical example: clothing combinations
These quantities are illustrative, not a benchmark or client result. One shirt has three colours and four sizes, giving 12 possible combinations mathematically. The supplier makes only ten, and two of those ten are currently out of stock. A useful master distinguishes a combination that never exists from one that exists with zero available stock.
The merchant selects five products for the trial: a simple item, a colour-and-size family, an item with an option-specific price, an item with a colour-specific image and an unavailable item. An employee reviews the customer-facing selection, the test order and the fulfilment details. A correct-looking label with an incorrect SKU is a failed test, even if the page looks polished.
Once the sample is approved, the team keeps a dated master, loads the remaining scope and reconciles parents and variants separately. The merchant approves the facts; the implementer verifies the transfer; the tester documents purchase behaviour. Keeping those responsibilities distinct prevents the last person who touched the file from becoming the accidental owner of every product claim.
Accept the data in the live buying journey
Within software quality assurance, link each representative product to its approved source record. Check identity, price, stock and image, then select the variant, add it to the basket and inspect the resulting order. Review Arabic mobile presentation, particularly mixed-direction model codes, units and size labels.
Test stock maintenance separately. Who changes it, in which system, and how will they avoid overwriting it with an older file? Agree how to pause an affected product and investigate a discrepancy without reloading the entire catalogue indiscriminately.
Typical mistakes include copying a nearby product's description, using the wrong colour photograph, holding inventory only at family level when sizes differ, and allowing campaign deadlines to override data approval. A proposal for “200 uploaded products” should explain whether the count includes variants and content review or simply data entry.
Frequently asked questions
Does every size need a separate page?
Not automatically. Choose the structure around the relationship between items and how shoppers select them, then verify the platform representation. A convenient spreadsheet structure should not force a fragmented shopping experience.
Who approves supplier information?
The merchant or their authorised product specialist. The implementer's role is to organise and load information within scope, not invent or independently guarantee missing specifications.
Can incomplete products be loaded first?
They can be prepared without publication where the chosen workflow supports it. Do not expose provisional facts to shoppers; define a publication gate for each group.
Is testing one product enough?
Not when different rules exist. Use a sample covering option, price, imagery and availability differences rather than only the easiest item.
Start with an approved sample
Prepare five products representing the hardest cases, with image files and price and stock sources. Approving that representation first makes the remaining effort and acceptance work much easier to estimate.
Source
Reviewed 26 October 2026: Salla product options and quantities.