WishlistGenius
When a saved size or color is confirmed discontinued, explain that the saved choice is unavailable and require the shopper to choose any replacement. Show the original options only when the retained details are reliable. Do not make the parent product’s availability look like availability of the saved option.
Start by checking two separate things: whether the combination was actually retired, and whether the saved entry still identifies it reliably. Those answers determine which message and actions are appropriate.
Diagnose the saved choice before changing its message
Hypothetical example: A shopper saves a blue shirt in medium. Later, the merchant retires that combination but continues selling the shirt in other sizes and colors.
Review the retirement decision and whatever catalog history your team retains. A missing variation record alone does not establish permanent discontinuation: knowing that a record disappeared is not the same as knowing why.
Separately, inspect the saved entry’s product identity, variation identifier, and option details. Do not assume deleting a catalog variation leaves its labels available elsewhere. Knowing which combinations were retired does not prove which one this shopper saved.
Use these findings to choose the display:
- Confirmed retirement and reliable saved details: Use the discontinued-choice card below.
- Original choice cannot be identified reliably: Use the uncertainty fallback, even if some catalog retirements are known.
- Confirmed temporary stockout: Use stockout wording, not discontinuation wording.
- Known choice but unresolved reason for unavailability: Use neutral wording such as “This saved option is currently unavailable.”
Everything below is a proposed implementation specification, not a claim about features your current wishlist already supports.
Show the original choice when its details are reliable
For this version of the hypothetical example, assume retirement is confirmed and the retained data reliably identifies blue, medium. A ready-to-adapt card could read:
- Product: Everyday shirt
- Your saved choice: Blue / Medium
- Status: Saved option discontinued
- Message: This size and color combination is no longer offered. Review the shirt’s current options to choose a different one.
- Primary action: View current options
- Secondary action: Remove saved item
The status belongs to blue, medium, not necessarily to the whole shirt. Avoid an “In stock” label inherited from the parent product: it would contradict the status of this saved choice.
If the original image is unavailable, use a neutral placeholder or clearly labeled general product image. Another color’s photograph should not appear to represent the saved choice.
Omitting a purchase price is clearer than displaying another variation’s price on this unavailable card. If a reliably retained historical price is shown, label it as historical, not a current offer.
Acknowledge missing details without guessing
Now change one assumption: the entry still identifies the parent shirt, but the saved variation’s size and color cannot be identified reliably from the retained data.
Use a fallback such as:
- Product: Everyday shirt
- Saved options: Could not be identified
- Message: We can’t identify the size and color you saved. Review the current options and choose again.
- Primary action: View current options
- Secondary action: Remove saved item
Keep any fields that remain reliable and adjust the message to name only the missing details. A missing size does not require hiding a known color. Defaults, product photographs, and popular combinations are not evidence of the original selection.
An unidentified saved variation must not be added directly or resolved to a default variation. Apply the request-handling requirements below to this fallback too. A reliably identified parent provides a route to current options, not proof of what the shopper saved.
If the parent cannot be identified reliably either, use a generic unavailable-entry message and a route to browse the catalog. Do not guess a destination or promise recovery.
Control the path from unavailable item to replacement
Prevent an invalid cart addition
For both retired and unidentified saved choices, specify that the card must not offer a working “Add to cart” action. Replace it with the appropriate navigation action and keep the explanation visible beside it.
Ask the developer to verify request handling as well. Hiding or disabling a button is insufficient. A stale request from an older open page, or a direct request that bypasses the visible button, must not add the unavailable choice or silently substitute another variation. Require a clear response explaining that the saved choice cannot be added.
Let the shopper review and confirm another combination
Suppose the hypothetical catalog now offers blue in large and white in medium. Neither preserves the original choice: one changes the size, the other changes the color.
“View current options” should lead to selection, not automatic replacement. The shopper must select or explicitly confirm clearly displayed replacement options, with their current price and availability shown before adding them to the cart. Merely opening a product page containing a default selection is not confirmation.
Keep saving and removal deliberate
Opening the product page must not rewrite the saved entry. Any replacement save should require an explicit shopper action.
If the existing interface supports only separate saving and removal, keep those steps separate rather than promising a replacement control it does not have.
Saving an item does not reserve stock, lock its price, or grant permission to email the shopper. The return journey should imply none of those things.
Verify the returning shopper’s journey
Try these checks on a test store using sample entries.
Start with one retiring variation: record which saved details remain reliable, adapt the matching card, and give your developer the action rules. Complete the staging review from the old saved entry through the final cart selection before applying the changes more widely.