Flux ArtWhy connecting images by SKU alone can go wrong
Before a team creates e-commerce assets with Flux Art, it needs to confirm which actual product each image represents. Two stores may happen to use the SKU 001: one sells a single white cup, while the other sells a black two-cup set. If the two sheets are joined on the bare SKU, neatly named files can still be linked to the wrong product. Save a stable identifier for the platform, store, or seller account together with the original SKU to form an external product key with a defined scope. Then map that key to an internal product ID the team has verified. This is an asset-management method; it does not mean Flux Art automatically recognizes SKUs, maintains product master data, or determines product identity for the team.
Step 1: Preserve the original value and define who owns the code
Do not remove leading zeros, standardize letter case, or strip hyphens just to make a spreadsheet look consistent. A character that is insignificant in one source may be part of an identifier in another. Store the original value and normalized value in separate columns, and have the owner of that source confirm the rules. A store's display name should not be the sole identity field either, because the same account may be renamed. Prefer a stable identifier that locates the source, and record where it came from. If no stable identifier is available, mark it as needing evidence rather than inventing a value and treating the mapping as certain.
Step 2: Make each mapping row reviewable by someone else
A reviewable mapping table should answer at least these questions: Who is the source? What is the original product code? What is the actual product and selling configuration? Which internal ID does it map to? Who approved it, on what evidence, and for what period? The internal ID must not stand for only a broad style; when color, capacity, item count, or included accessories change the image's meaning, distinguish the relevant sellable variant. Give image assets and file revisions their own fields; do not squeeze product identity, image version, and publishing location into one code. The fields and decision method below are illustrative, not real data from a store or a fixed template for importing into any platform.
| Field to verify | What to record | What to do if it is missing or unclear |
|---|---|---|
| Source namespace | Platform and stable store or account identifier | Isolate records with no source; do not merge by SKU alone |
| External product key | Keep the source identifier and original SKU in separate fields; preserve the original value | Do not overwrite the original value until normalization rules are confirmed |
| Actual selling configuration | Evidence for specifications, color, quantity, packaging, and accessories | Mark for evidence review when the name matches but the configuration is unknown |
| Internal product mapping | Approved internal product or sellable-variant ID | Stop assignment if one external key points to multiple products |
| Approval and scope | Evidence, reviewer, effective time, and expiry conditions | For reused legacy codes, retain history and review again |
| Image asset and revision | Asset ID, version, and purpose for the original or finished image | Deliver separately when the product matches but image copy or use differs |
| Actual placement | Store listing, page, image slot, and verification record | Recheck the current mapping when the page configuration changes |
Step 3: Separate different products with the same code; do not let a later row overwrite an earlier one
Suppose Store A's 001 is a single white cup and Store B's 001 is a black two-cup set. Their store-scoped external product keys differ, so they should map separately to the corresponding physical products and internal IDs. If an automated process reads only the SKU column, it should stop in a review queue rather than pick the first row or let the last one overwrite it. After adding the store field, also verify the cup color, package quantity, and included accessories. Removing duplicate values from a spreadsheet only means rows were deleted; it does not prove the conflict was resolved. Keep both original records and the reason for the decision so the team can explain why it used a particular product image.
Step 4: Merge different codes for the same item only when evidence supports it
Another hypothetical case: Store A uses CUP-W1 and Store B uses 001, and both really sell the same supplier-version white single cup. A responsible reviewer can check the physical product ID, specifications, packaging, and selling configuration, then map both external keys to one internal product ID. Do not merge them solely because their Chinese product names match or their thumbnails look alike. Even when product identity matches, the language on the main image, platform promotion, or gift included with an order may differ. Sharing an original product image does not mean every finished image can be used across stores. Record both the approval of product identity and image-use restrictions; check the latter separately at the delivery location.
Step 5: Isolate reused legacy codes and missing sources
Suppose a store once used 001 for an older model and later reused it for new packaging. The store and SKU alone are no longer enough to tell which sales period a historical image belongs to. Record the source product identifier, selling configuration, and effective date range; retain the old mapping instead of rewriting history in place. If the old and new products cannot be distinguished, set the status to conflict pending review and do not assign images automatically. Missing store identifiers, one external key pointing to different products, or expired approval evidence should go into the same review queue. Pending review does not mean deleting the asset, nor does it mean forcing an uncertain record onto the most similar product.
Step 6: Verify images where they will actually be used
After creating the mapping, check a small set of representative records: one each for same-code/different-product, same-product/different-code, reused legacy code, and missing fields. Confirm that the output matches expectations. These are hypothetical cases, not real test results. For delivery, record the store, product page or listing, image purpose, asset ID, and image revision for each placement, then recheck the product, specifications, and set contents on the current page. A valid source mapping paired with the wrong file revision is still not ready to deliver; a correct file must also be held for review if the product page now shows a different selling configuration. Do not carry one successful mapping forward indefinitely to every later campaign.
Step 7: Change only relationships supported by evidence
When a reviewer approves a new mapping for an external key, record the old and new values, evidence, approver, and effective time, then list the affected image placements. Unaffected stores and products do not need to be redone. Retain historical orders, approved mockups, and old mappings as traceability records instead of overwriting them with the latest state; recheck current listings against the current product. Records whose impact is unclear should remain marked as needing evidence. This boundary separates product-identity mapping from asset-version issues, but it does not guarantee that images will never be mismatched later; check them before each actual use.
How to bring this table into image creation
You can first prepare authentic product photos and verified mappings, then visit https://flux-art.net/en/ai-ecommerce to explore Flux Art's e-commerce visual creation entry point. Specify the background, layout, or text work needed, and keep the evidence for checking product identity and selling configuration. An image generated or edited with AI cannot, in turn, prove that two SKUs belong to the same product or that an accessory is included in a sale set. Before delivery, check that the product, image revision, and placement correspond. If the evidence is still insufficient, leave the row marked as needing evidence and keep it out of the approved image package.