How SKU thumbnails change when their material is edited
Learn why a SKU's display picture is replaced automatically whenever its material is saved or attached, and how to keep material updates from wiping settings.
A SKU with a material attached does not keep an independent thumbnail. Two sync rules cause this. First, whenever a material is saved with a new texture or a new colour, every SKU using that material gets its display picture replaced in the same operation: textured materials use the texture's image, plain-colour materials get an auto-generated flat colour swatch. Second, whenever a material is attached to a SKU through catalogue bulk editing, the SKU's display picture is set to the material's swatch, overwriting any custom thumbnail the client had uploaded. So when a client asks why their SKU images changed after editing a finish, or why a custom product photo disappeared after assigning a material, this is expected behaviour, not corruption. They can re-upload a custom picture afterwards, but the next material edit will overwrite it again. One more edge: a material saved with neither a texture nor a colour gets no swatch at all, so the material (and any SKU it is attached to during bulk edit) shows a blank thumbnail in pickers.
Catalogue profile images are not independent: when the catalogue owner edits the item's material (a new texture or colour), the profile's displayed image is replaced automatically, so an image that looked different earlier may change after the update.
A unit's displayed thumbnail is a derived display picture, so it can lag behind the unit's actual drawing or configuration.
The unit's real behaviour is defined by its SKU properties and drawing, not by the thumbnail image.
The material update endpoint demands id, name, material_template_id and properties on every call; omitting any of them fails with MATERIAL_UPDATE_FAILURE. There is no partial update: you cannot 'just rename' a material without resending its template id and complete properties, and whatever properties object you send replaces the stored one entirely. Combined with the validation rule that only unknown keys are rejected while missing keys pass silently, this creates the classic data-loss scenario: a client updates a material 'to change roughness' with a trimmed payload containing only the roughness key, the save succeeds, and every other setting (colour, texture maps, opacity, metalness...) is gone. The safe workflow to give clients: fetch the current material, modify the specific values in the returned properties object, and resend the whole thing. Also remember every successful update re-derives the material's display swatch and rewrites the thumbnails of all SKUs using that material, so a bad update is visible across the catalogue immediately — which also means a correct re-save with the full payload repairs both the material and the SKU thumbnails in one go.
After updating a catalogue material colour, refresh the cache from the first line of the Production Settings tab so the new colour shows in the design.
The Refresh Cache option is the first item on the Production Settings tab.
✓ 16 ઑક્ટોબર, 2026ના રોજ પ્રોડક્ટમાં ચકાસેલRefresh Cache applies not only to edited material colours and finishes but also to other edited catalogue item properties, such as procurement details, so those updated values reach the design once the cache is refreshed from settings.