A Variant and Pricing-Tag Overlay Workflow

A mid-size e-commerce catalog commonly has 500 to 2,000 active SKUs. Each SKU may have 4 to 8 color variants, and each color variant may need 3 to 5 image angles. Multiply these numbers and the image production requirement for a single catalog refresh easily reaches 50,000 individual assets. If each asset also needs a pricing tag (base price, sale price, percentage discount badge), the number of unique text values that must be correctly applied is equally large.

Manual production of this scale is simply not feasible without a dedicated design operations team working for weeks. But the deeper problem is not just speed — it is accuracy. A pricing tag applied to the wrong variant or a discount badge showing an incorrect percentage is a compliance issue and potentially a legal issue in markets with price advertising regulations. Every manually applied pricing element is an opportunity for a human error that may not be caught before the asset goes live on a storefront.

A variant and pricing-tag overlay workflow in Floniks eliminates both the speed problem and the accuracy problem. The workflow ingests a structured data feed (a JSON or CSV file containing variant IDs, color values, prices, and discount percentages) and generates or retrieves one image per variant, then applies the correct pricing overlay for each variant based on the data feed values. The output is a correctly named, correctly priced image file for every variant, produced without manual entry at the per-asset level.

The workflow begins with a Data Feed Ingest node that accepts a structured data file describing the product variants. The minimum required fields are: variant ID, product name, color name, hex color value, base price, sale price (if applicable), and discount percentage (if applicable). Additional fields such as size label, material description, or promotional badge text can be included and mapped to overlay elements.

In the Floniks editor, the Data Feed Ingest node parses the file and emits one execution token per row. Each token carries all the field values for that variant as named variables — {variant_id}, {color_name}, {hex_color}, {base_price}, {sale_price}, {discount_pct} — that downstream nodes can reference. This pattern means the entire graph executes once per variant automatically, without the producer manually triggering each variant separately.

Validate the data feed before running the full workflow by enabling the Preview Run option on the Data Feed Ingest node. This runs the workflow for the first five rows in the feed and produces sample outputs. Review the sample outputs to confirm that pricing values are being correctly applied and that color variants are generating or matching correctly. Once the sample outputs are correct, disable Preview Run and execute the full workflow. For feeds with hundreds of rows, the workflow processes variants in parallel batches, dramatically reducing total execution time compared to sequential processing.

There are two methods for generating color variant images depending on the product type. For products where color change is a simple surface-level swap — solid-color apparel, monochrome accessories, uniform-surface home goods — a Recolor node accepts the base product image and the target hex color from the variant data token, then applies a precise color substitution while preserving texture, shadow, and highlight detail. The prompt template is: "product image, color changed to [hex_color], preserve fabric texture and surface detail, same lighting, same framing, same background, no other changes."

For products where color change involves pattern differences, material changes, or multi-color designs (plaid shirts, printed cushions, marble-look tiles), a full variant generation approach is needed. The base product image serves as a layout and pose reference, and the Generation node receives a prompt that describes the variant: "same product layout and framing, [color_name] colorway with [material_description], preserve shadow direction and background, product photography quality." The image strength should be 0.5 to 0.65 to allow the color and pattern to change while keeping the product pose and camera angle stable.

For product lines where a photorealistic studio shoot exists for one hero color and AI needs to extend coverage to additional colors, use the hero color image as the conditioning reference for all AI-generated variant colors. This ensures that all variant images share the same compositional reference — same angle, same studio lighting style, same background treatment — even though they were generated at different times. Consistent reference conditioning is the most reliable method for maintaining cross-variant visual consistency in large catalogs.

After the variant image is generated or retrieved, it passes to a Pricing Tag Overlay node that draws the pricing information from the variant data token. The overlay node renders three elements: the base price in standard body weight, the sale price in a larger bold weight with a brand accent color, and the discount badge as a pill or starburst shape containing the percentage formatted as "-X%."

Each element's value is drawn directly from the {base_price}, {sale_price}, and {discount_pct} variables in the data token — no manual entry is possible and no human error in price assignment can occur. The overlay node also applies conditional logic: if the discount_pct field is empty (meaning the variant is not on sale), the discount badge element is suppressed entirely and the sale price field is also hidden. Only variants with active promotional pricing show the badge — correct promotional pricing display is enforced automatically.

The output of the Pricing Tag Overlay node passes to a File Naming node that constructs the output filename from the variant data: "{variant_id}{color_name}{platform}.jpg." Platform-specific exports (storefront full resolution, mobile thumbnail, ad creative crop) are handled by downstream resize nodes feeding into the File Naming node with the platform label filled in. All files land in an export folder organized by product ID, making bulk upload to a storefront platform a drag-and-drop operation. Save the complete workflow as a reusable template for the catalog; when prices change for a sale event, update the data feed file, re-run the workflow, and only the changed variants are re-exported with the new pricing values.

For pricing overlays in regulated markets, automated quality control is not optional — it is a compliance requirement. The Floniks workflow supports a post-render QC node that reads the pricing text values from the rendered image using OCR and compares them against the expected values from the data token. If the rendered sale price does not match the data token sale price — a situation that can arise from rounding errors in the text renderer or font encoding issues with currency symbols — the QC node flags the variant as failed and excludes it from the export batch.

Failed variants are written to a separate QC failures report with the variant ID, the expected values, and the detected rendered values. The producer reviews only the flagged items rather than manually spot-checking every output in a large batch. Typically fewer than 1% of variants fail QC, and the failures are concentrated in specific character-set or currency-symbol edge cases that can be fixed once in the overlay configuration and then resolved in a re-run.

For international storefronts, configure locale-specific pricing overlay nodes for each market. A variant selling in the US shows USD pricing; the same variant selling in the EU shows EUR pricing with the correct decimal formatting (1.299,00 rather than 1,299.00). Each locale-specific overlay node draws from a locale-specific column in the data feed. Run all locale variants in parallel using the Data Feed Ingest multi-output pattern. The result is a complete, correctly formatted, QC-verified image package for every variant in every market from a single workflow run.