Product Import Guide

The product import is the most complex and consequential import in a Norce integration. Mistakes here can cause silent data corruption, products that never appear on the storefront, or shipping logic that doesn't work. This guide covers the decisions you need to make correctly before writing a single line of import code.

API Reference: ImportProducts
Header reference: ProductHeader — Working with the X-Stormconnect-Header

The product model

Norce uses a three-level product hierarchy:

Product
  └── Variant (also called Variant Cluster)
        └── SKU

• Product — the top-level entity. Holds the manufacturer, shared content (name, description), categories, and product-level parametrics.
• Variant — groups SKUs that share the same physical form. Holds ManufacturerPartNo, logistics data, and variant-level parametrics (e.g. color, size).
• SKU — the orderable unit. Has PartNo, Status, Type, price, and on-hand data.

For products without variants, the hierarchy still exists — there is simply one variant with one SKU.

Required fields to create a product

A product import that is missing any of these will either fail or produce a product that cannot function correctly in Norce.

The ManufacturerCode + ManufacturerPartNo uniqueness rule

This is one of the most common sources of silent data corruption in product integrations.

Norce uses ManufacturerCode + ManufacturerPartNo as a composite key to identify a variant. If two products in your import have the same combination, one of them will overwrite the other without any error or warning — and since import is an async batch process, the order of processing is not guaranteed. You will end up with one product where you expected two.

This situation typically occurs when:

• Your source system uses manufacturer part numbers inconsistently or allows duplicates
• Multiple sources use the same manufacturer part number for different products
• Data is migrated from a legacy system without deduplication

Always validate uniqueness of this pair before sending the import. If your source data contains duplicates, you must resolve them (by adjusting one of the values) before importing.

Letting Norce generate PartNo

PartNo can be omitted when creating a product. If manufacturer information is present and all other required fields are provided, Norce will generate a PartNo automatically according to the numbering scheme configured in the Admin UI. This is a reliable way to ensure uniqueness — if you are not importing a pre-existing article number from a source system, letting Norce generate the number avoids the risk of collisions.

Once generated, the PartNo is permanent and cannot be changed. Subsequent imports must reference the assigned PartNo to update the product.

Product statuses

Status controls the product lifecycle in Norce. Use the appropriate status — do not model your own lifecycle using flags if a built-in status fits.

Recommended practice: Set new products to Coming on creation using StatusCreateOnly in the header (code 22 in SkuFieldsThatAreSet). This prevents the ERP from overwriting a status that has been manually changed to Active in the Admin UI on subsequent imports. See Working with the X-Stormconnect-Header.

Product types

Type controls how Norce handles a product in the ordering and stock flow. Choosing the wrong type is a common mistake that affects order processing, stock display, and ERP integration.

Note on naming: In the Norce Admin UI and in some older contracts and documentation, ErpStandard may appear as simply Standard. These refer to the same type (value 1). Type value 14 (formerly a distinct "Standard" type for non-ERP products) has been deprecated and removed — only value 1 remains in use.

The most common mistake is selecting the wrong product type for your fulfillment setup. If your ERP is the order fulfillment system, all physical sellable products must be ErpStandard — otherwise Norce will not send the order to your ERP when the product is purchased.

For an overview of all product types and their current usage in Norce, see the Product types reference in the user portal.

Built-in fields vs. parametrics

This is one of the most consequential mapping decisions in a product integration. Some product attributes have dedicated built-in fields in Norce's data model. Putting these into parametrics means the data is there visually, but Norce's business logic cannot use it.

Fields that must be built-in (not parametrics)

These fields feed Norce's shipping and logistics calculations. They only work when mapped to the correct built-in SKU or variant fields.

VolumeWeight (formerly code 15) is deprecated and no longer supported. Use ActualWeight and the logistic dimension fields instead — Norce calculates volumetric weight from those.

For the full list of built-in product fields and their semantics, see Product settings in the user portal.

Fields that should be parametrics

Everything else that is product-specific but does not feed a built-in Norce calculation belongs as a parametric. Examples:

• Technical specifications (wattage, voltage, material, dimensions in a product data sheet)
• Color and size (when used as variant-defining attributes)
• Certifications and compliance markings
• Product-specific delivery or assembly notes

Parametrics are flexible, multilingual, and filterable. They are the right place for any attribute that buyers use to compare or filter products.

Product flags

Flags are boolean attributes — set or not set. Unlike parametrics, flags apply to all products in the catalog regardless of category. This makes them the right tool for cross-cutting concerns that span many product types.

Norce also has built-in business logic that can act on flags — such as filtering search results, triggering workflows, or controlling feature availability. Flags are therefore useful for integrations that need to signal state to Norce or to downstream storefront logic.

Common flag use cases

• Multi-market publishing — IsPublishedSweden, IsPublishedNorway, etc. A product's Status is global across all markets, but a flag group can express per-market visibility independently. This is a very common pattern for merchants selling to multiple countries.
• Campaigns and seasonal products — flag a product as part of a campaign or as a seasonal item. Useful for driving storefront merchandising logic without changing the product's lifecycle status.
• Enrichment workflow triggers — an integration can set a flag on newly created products to signal that they need manual enrichment in the PIM. Workflow tooling can then filter on this flag and clear it when enrichment is complete.
• Assortment classification — for example, IsMarketplaceEligible or an ABC inventory classification flag. These typically come from the ERP or a separate business process.
• Special offers and agreements — flag products that have a special price agreement, or that are available for backorder.

Flags vs. statuses — when to use which

The key distinction: Norce statuses control the product lifecycle — they affect visibility, stock behavior, and order processing in ways that are built into the platform. Flags are yours to define and carry meaning in your business logic, storefront code, and workflows.

Do not create a flag to replicate what a Norce status already does. Do not use Status to express a business concept that belongs in a flag.

Flags must be created in Norce before products referencing them are imported. See Metadata Integrations.

Variantization

Variants model products that come in multiple configurations — sizes, colors, capacities — where each configuration is a separately orderable product with its own PartNo.

You do not have to variantize at import time

It is entirely valid to import products as flat, unvariantized SKUs and leave variantization to be done later in Norce's PIM. Nothing is lost data-wise — the products are created correctly, and a content team can group them into variants in the Admin UI afterwards.

Variantizing through the import makes sense when your source system already carries reliable variant grouping information. If the grouping information is ambiguous or inconsistent in the source data, it is often safer to import flat and structure variants deliberately in Norce.

When variant structure can be inferred from the source

Some source systems express variant relationships through naming conventions rather than explicit grouping. For example, article numbers with a shared prefix and variant-specific suffixes (SHIRT-BLK-S, SHIRT-BLK-M, SHIRT-RED-S) carry the grouping implicitly. In this case, the integration can:

1. Parse the common prefix as the base product identity — use this as the shared Product.Code stem
2. Identify the suffix values as the variant dimensions (color, size)
3. Create or reference the corresponding VariantDefinitionGroup in Norce
4. Assign each SKU to the correct variant within the group

This kind of inference logic belongs in the integration layer, not in Norce. The output is a standard variant import — Norce just receives correctly structured data.

Mapping from a source system with variants

If your ERP or PIM has a variant concept, map it as follows:

Variant groups

The dimensions that define variants — size, color — are configured as a VariantDefinitionGroup in Norce. When a variant definition group is referenced on the product, Norce knows which parametrics are the variant-defining ones and can present them correctly in the storefront and Admin UI.

A VariantDefinitionGroup is not strictly required for the product hierarchy to exist — you can import a product with multiple variants without one, and the structure will be created. However, without it there is no context telling Norce or the storefront which parametric represents color versus size. This works but is not common practice. Whenever you have resolved that a set of products vary by color, size, or another defined dimension, you should create or look up the correct VariantDefinitionGroup and reference it in the import.

Create and manage variant groups via the Management API — see Metadata Integrations.

The product code and variant structure

The Code field on the product level signals to Norce that this product is part of a variant family — that the product-variant structure is intentional and more variants may be added later. If you import a product with a single variant and a single SKU and include a Code, Norce treats it as a variant-structured product. If you omit Code, Norce treats it as a standalone product.

In practice:

• If you know a product will have multiple variants, or you expect more variants to be added later — set a Code.
• If you know this is a single-SKU product with no variants — leave Code out.
• If you are unsure — leave it out until you need it.

Products without variants

Even a product with no variant dimensions has one variant and one SKU in Norce's model. In this case:

• ManufacturerPartNo on the variant equals the product's own identifier from the source system
• There is exactly one SKU with its PartNo

Import contract restrictions

ImportProducts handles product structure, content, and basic pricing — but two types of data are intentionally excluded from the contract:

On-hand (stock) — stock figures are never included in ImportProducts. They are always a separate import via ImportOnHands. Products must exist in Norce before on-hand records can be created for them. If your source data includes both product information and stock levels, split them into two separate imports and ensure the product import runs first.

Multiple price lists — ImportProducts supports only one price list per call. If you need to populate multiple client price lists, use ImportSkuPriceLists as a separate import. Like on-hand, price list records require the products to already exist. A common approach is a thin first pass (product structure and creation) followed by separate parallel imports for on-hand and all price lists.

A multi-step import strategy

The completeness of a product record in Norce often grows in stages. Trying to do everything in one import call makes the integration fragile and hard to debug.

A practical approach:

1. Thin first import — the mandatory keys and built-in settings. ManufacturerCode, ManufacturerPartNo, PartNo (or let Norce generate it), Status, Type, primary category, and any built-in fields like logistics dimensions, EAN, and unit of measurement. Built-in fields are lightweight and have no performance impact, so including them here rather than in a later pass is fine. The goal of this step is to ensure all products exist with correct keys before anything else depends on them.

2. Content and enrichment imports — the heavy metadata-defined structures: product names, descriptions, images, parametrics, flags, and variant grouping. These involve large metadata-dependent structures and are often maintained by a separate PIM or DAM system. They can run after products are created and can be re-run incrementally as content matures.

3. On-hand and price imports — once products exist, these can run independently of each other and independently of step 2. They do not need to wait for content enrichment — the only hard dependency is that the products themselves are created.

This structure makes each import leaner, more debuggable, and easier to retry selectively when something goes wrong.

Validating your product import

Start by checking the Connect job status. Every import returns a job ID — check it in the Admin UI under Integration Status, or subscribe to the JobCompletedEvent. A completed job with errors tells you which records failed and why without needing to query individual products. See Job integration examples for programmatic job status polling.

Once the job has completed successfully, use Norce Commerce Query for targeted spot checks. Query is designed for application use and can be expensive for large result sets — use it for sampling and specific lookups, not for iterating through every product in a large import.

/ProductSkus?$filter=PartNo in ('SKU001', 'SKU002', 'SKU003')&$select=PartNo,Status,Type,ManufacturerCode

Spot checks to run:

• Primary category is set: /ProductSkus('SKU001')?$expand=Categories($filter=IsPrimary eq true)
• Status and Type are what you intended
• Parametrics are present: ?$expand=Parametrics
• Logistics fields are set: check ActualWeight, LogisticWidth etc. on the variant

Further reading

• ImportProducts API reference
• ProductHeader specification
• Working with the X-Stormconnect-Header
• Metadata Integrations
• Products and pricing integrations
• Product integration scenarios
• Product integration examples