Creating Products
June 26, 2026
Summary
How the Product Builder turns inventory variants into products and listings - the identifier priority order it evaluates to avoid duplicates, what each inventory variant status means, and the two ways to resolve Builder Issues.
Creating products
How the Product Builder decides what to do with each inventory variant
The builder evaluates identifiers in priority order - most specific first. Understanding this order is the key to preventing duplicates and resolving Builder Issues.
| Condition | Result | What to do next |
|---|---|---|
| Matches existing product by Master SKU | Links to that existing product variant | No action needed - verify quantity and pricing in the variant. |
| No Master SKU match - matches by UPC, GTIN, or secondary ID | Links to matching product. Multiple records sharing the same identifier are merged into one variant. | Assign a consistent Master SKU to improve future matching reliability. |
| No match on any identifier | New product and variant created | Review the new record - confirm title, SKU, cost, and images are correct. |
| Identifiers match but data contradicts Builder rules | Flagged as Builder Issue - paused for review | Open the variant, read the conflict description, choose Nope, Delete or Looks Good, Build Again. |
Important: read before building
Master SKU is the most reliable deduplication key
Without consistent Master SKUs, the builder falls through to UPC matching - which produces false positives when two different products share a UPC due to supplier data errors. Define and standardise Master SKU mapping during inventory import. Consistent Master SKUs across all sources prevent duplicates more reliably than any other setting.
"Nope, Delete" doesn't permanently fix a Builder Issue
Clicking Nope, Delete removes the flag but not the underlying condition. If the same inventory rebuilds under the same conditions, the issue reappears. Fix the root cause first (duplicate SKU, wrong UPC, wrong parent assignment), then use Looks Good, Build Again.
Auto Create Listings skips data quality validation
Enabling Auto Create Listings pushes inventory → product → listing in one step with no review window. For first-time builds with a new supplier, build products first, spot-check 5–10 records, then create listings separately. For trusted suppliers you've used before, Auto Create Listings is fine.
Multiple records sharing one UPC get merged into one variant
When inventory records from different sources share the same UPC, Flxpoint consolidates them into one product variant - this is intentional. Pricing and quantity rules then determine which source's values are used. If records are genuinely different products with the same UPC in the supplier data, assign distinct Master SKUs to keep them separate.
Default variant custom field mapping
You can now configure default mappings for variant custom fields within the Product and Listing Builder settings. This ensures that specific source-level variant data automatically populates your product and listing custom fields during the build process, reducing manual entry for new items.
SKU prefixes are required for source inventory
A prefix must be added to every source to ensure uniqueness across your catalog. This creates a new identifier (Prefix + Supplier SKU) in the Master SKU field without modifying the original supplier data, preventing collisions between different sources.
Bundle products supported for Master SKU linking
Bundle products now appear in the Master SKU selection grid when linking listings. You can link a listing to a bundle product using the same process as a standard product, ensuring consistent identifier management across all product types.
Inventory variant statuses
| Status | What it means |
|---|---|
| Not Linked | Variant exists in Source Inventory but hasn't been selected for product creation yet. Use the Not Linked quick filter in Source Inventory to see all unbuilt variants. (The No Products filter is used on the Standard platform.) |
| Building | Product Builder is actively processing this variant in the background. You can navigate away while it runs. |
| Builder Issue | Variant is blocked by a rule conflict or data mismatch. The builder paused to prevent an incorrect link. Use the Builder Issue filter to find all affected variants, then open each one to read the specific conflict and resolve it. |
| Linked | Variant was successfully created as a new product or linked to an existing one. Inventory now flows into the Product Catalog and is available for listings and routing. |
| Deleting | Variant is queued for deletion from the UI in the Source Inventory section. |
Resolving Builder Issues: two choices
Open the variant detail page. The Builder Issues section explains the specific conflict. Then choose one action:
| Action | When to use it | What happens |
|---|---|---|
| Nope, Delete | The flag is a false positive you've investigated and confirmed is not a real conflict | Dismisses the flag. Variant stays in its current state. Issue reappears if the same inventory rebuilds under the same conditions. |
| Looks Good, Build Again | You've reviewed the conflict, corrected the underlying data, and are ready to proceed | Acknowledges the conflict and builds. May modify existing product links or require a new SKU assignment. Read the conflict description carefully - it will state exactly what will change. |
Product Builder: key settings reference
| Setting | What it controls |
|---|---|
| Product Match Rules | Which identifiers (UPC, SKU, Brand+MPN) the builder uses to match inventory to existing products. More specific rules reduce false-positive merges; broader rules increase auto-linking. |
| Identify Mismatches | Extra validation that fires when a potential match is found - catches false positives where different products share the same UPC. When a mismatch is detected, the variant is flagged as a Builder Issue rather than silently linked incorrectly. |
| Rebuild Settings | Controls when products automatically rebuild when their source inventory changes - after a new import or when source priority changes. Auto-rebuilding keeps catalog data current without manual triggers. |
| Source Priorities | Ranks sources so higher-priority sources override data from lower-priority ones when multiple sources contribute to the same variant. Set the source with the richest product data (images, descriptions) as highest priority. |
| Actions on Conflict | What happens when the builder detects a conflict: Build (proceed), Fail (pause with Builder Issue), Attach Variants (add to existing product), or Use Variant (link to most relevant existing variant). |
Common issues
Duplicate products in the catalog after building
Duplicates form when inventory from different sources doesn't share a matching identifier - the builder creates a new product for each unmatched variant. Fix: (1) Confirm Master SKUs are consistent across sources - if Source A calls it
WIDGET-001 and Source B calls it WGT001, they won't match. (2) If Master SKUs are absent, ensure UPCs are present and consistent. (3) After fixing identifiers, rebuild the affected products - the builder will re-evaluate and link correctly.Source inventory items not appearing in the Product Catalog after import
Source inventory must be explicitly built into catalog products - it doesn't flow through automatically. Go to Products → Source Inventory, filter for variants with status Not Linked, select them, and click Create Products. If items were imported but are still Not Linked after running the builder, check for Builder Issues on those variants - a rule conflict may be blocking them.
Two different products were incorrectly merged into one
Two genuinely different products sharing the same UPC in the supplier data - a common distributor data quality issue. To separate them: (1) Assign distinct Master SKUs to each inventory variant so the builder uses SKU matching instead of UPC. (2) Rebuild the affected product - the builder will now treat them separately. (3) Enable Identify Mismatches in the Product Builder settings to catch similar false positives in future builds.
Inventory items linking to each other or to the wrong product variant
Happens when multiple source inventory records share an identifier that shouldn't be shared - typically a UPC collision across suppliers, or a SKU prefix that matches unrelated products. Check whether affected variants share a UPC or Master SKU that belongs to a different product. Assign distinct Master SKUs to force the builder to treat them as separate items, then rebuild. Also review the Match Rules in Product Builder settings - overly broad rules (e.g. Brand+MPN without SKU) increase the chance of false-positive linking.
Builder Issue keeps reappearing after dismissing with "Nope, Delete"
"Nope, Delete" removes the flag but doesn't fix the condition that triggered it. When the same inventory rebuilds - manually or via auto-rebuild - the builder re-evaluates and flags the same conflict again. The permanent fix is to resolve the root cause (correct the conflicting data: duplicate SKU, mismatched UPC, wrong parent assignment), then use Looks Good, Build Again after the data is clean.
Channel listing variants linked to the wrong product variant
Most commonly caused by a SKU or UPC collision between two source inventory records that built into the same product variant incorrectly. Go to the channel listing, check the linked product variant, and compare identifiers. If the wrong link exists, unlink the listing variant from the product, correct the Master SKU on the source inventory record so it matches the right product, and rebuild. The channel listing will relink to the correct variant on the next sync.
Variants stuck in "Building" status and not completing
Check the Logs section (near Notifications) and filter for Product Builder to see the job's status - note that the log entry doesn't show which specific variant linked or failed, only that the job ran. Re-select the variants and click Create Products to re-queue. If it consistently fails, check for inventory records with missing required fields - no SKU, or a SKU containing invalid characters - these can stall builder jobs without a clear error.
Different products from multiple sources incorrectly merged into one parent
This occurs when two suppliers use the same parent SKU for different items. To resolve this, navigate to your Product Builder settings and locate the parent attachment settings. Set 'When attachment finds an existing parent product with variants from a different source' to 'Create New Product Parent (Recommended)'. Flxpoint will then generate a unique 4-character hash (e.g., P123-a82j) and append it to the parent SKU to ensure the products remain separate.
PromoStandards products not appearing despite successful connection?
If Get Inventory (GIP) jobs run without errors but products are not imported, the supplier's XML response may have a namespace mismatch. This causes the Product ID and Part ID to return as null values. To resolve this, verify the raw XML response against PromoStandards XSD schemas using a tool like SOAP UI. If a namespace discrepancy is confirmed, contact support to update the JAXB mappings for that specific source to align with the supplier's format.
Product uploads stalled or only partially completing?
If your Store Catalog shows a high product count but only a small fraction are successfully uploading, a single variant with invalid data may be causing the job to fail silently. Check the Logs section for NullPointerException errors, which often occur when a required string parameter is missing in the source data. To resolve this, identify the problematic SKU in your source inventory, ensure all required fields are populated, and retry the upload. Note that using Filter Mode can also affect how upload batches are processed, so verify your filter settings if the upload count remains stagnant.
Cross-source variants not merging despite shared identifiers?
This often occurs when Get Inventory Primary (GIP) and Get Inventory Secondary (GIS) jobs are not staggered correctly or if SKU formats differ across sources (e.g., numeric-only vs alphanumeric). Ensure GIP runs fully before GIS to establish the Master SKU, and verify that the 'Find and match to existing product variants' setting is enabled in your Product Builder configuration. If duplicates persist, check for UPC collisions where multiple distinct MPNs share a single UPC, which may require specific mapping corrections to separate.
FAQs
What's the difference between the Product Builder and the Mapping Template?
They work together but do different things. The Product Builder is the matching and deduplication engine - it decides whether to create a new product or link to an existing one, and how to combine data when multiple sources contribute to the same variant. The Mapping Template controls how product fields are formatted and mapped when data gets pushed to channel listings - it shapes the output, not the matching logic.
Should I enable Auto Create Listings during product build?
Only if you're confident in the source data quality. For a new supplier, build products first, spot-check 5–10 records in the Product Catalog, then create listings separately. For a trusted supplier you've used before, Auto Create Listings is fine - it compresses the workflow without the risk of bad data propagating into live listings.
Can I rebuild a product after it's been created without losing my customisations?
Rebuilding overwrites all product data except price and quantity (these dynamic fields do not rebuild), by re-running the build process from source inventory - including any manual edits made in the Product Catalog. Titles, descriptions, and custom attributes you've edited will be lost on rebuild unless preserved through a Mapping Template or customisation workflow. Review which data is preserved before triggering a rebuild on products you've manually edited.
How do I handle inventory from a new source where the SKUs don't match my existing products?
Configure the Master SKU mapping in the new source's import settings to transform or standardise the supplier's SKUs before the build runs. For example, if your existing products use
WIDGET-001 and the new supplier uses WGT-001, a mapping rule can normalise both to the same format so the builder matches them correctly. If UPCs are reliable across both sources, UPC matching alone may also be sufficient.