Variants
To send variants to Shopify, several rules must be taken into account:
RULE 01. If the product has no variants, all the mandatory information must be configured in the product tab in the connector.
RULE 02. If you have both products and variants, should the channel find repeated fields, those variants will be the ones that prevail.
RULE 03. An unique SKU must be provided to identify each product or variant. The connector uses the SKU as the main reference to locate products and variants in Shopify.
If the connector detects more than one product or variant with the same SKU, it may cause unexpected behavior, such as creating duplicates or overwriting the wrong items.
RULE 04. Each variant of a product must have a value assigned for all the variant attributes. that have been defined for it, otherwise, it will not be synchronized (if the attribute exists in Shopify, it will be deleted).
RULE 05. Status. Shopify doesn’t maintain independent status (e.g., “unavailable” or “draft”) at the variant level.
Therefore:
1- If the connector is configured to export items with "All statuses" - the variants will be sent to Shopify regarding of the status
2- If the connector is configured to export items with "visible status" and the variants do no comply with this status ( e.g by marking them as "draft" or "invisible" in the PIM)- they will be excluded from the sync with the consequence of being removed in Shopify. If later these variants are re‑created (for example, by changing them back to “visible” status), they will receive new Shopify IDs. This is particularly relevant if those variants have been sold and related metrics are being pulled from Shopify.
Because Shopify IDs aren’t guaranteed to persist across such changes—even when a product’s attribute configuration is modified—it’s safer to rely on SKUs for tracking purpose. Using SKUs will help match old and new variants correctly, whereas Shopify IDs may not align after recreation
To sort the variants from the Sales Layer catalog and send this order to Shopify
1- Add the field to be sorted in the Variants tab and map it
2- Add the “sort_order” field in the Products tab.

3- Add one of the two formulas detailed below:
- field:asc|desc: For example:
PRINT(”price:asc”); PRINT(“price:desc”)
- field:custom|option1|option2: For example:
PRINT(“size:custom|XS|S|M|L|XL”)
In this second option, if you do not enter all the options for the variant, the system will follow the order of those indicated in this field but not those that do not contain any.
Fields correlation:
Connector Field
| Mandatory
| Description
|
---|---|---|
title | Yes Type: string | Variant name |
sku | Yes (internal Connector control). Type: string | Product reference
|
status | No |
|
No (it has to be mapped out if connector’s visibility filter = All items” Type: string|SalesLayer Status |
| |
options | Yes, at least 1 option. Type: All valid. | In order to create variants in Shopify it is mandatory to send at least one configurable field
Example of options are “color” or “size” |
price | No Type: decimal | Price
|
barcode | No Type: string | Barcode |
taxable | No Type: string| | true|yes|sí => Indicates whether a tax is applied to a product (the VAT of this product). no => Does not indicate. |
template_suffix | No Type: string | Theme template Map with one of existing values, the themes must be either created or bought from Online store > Themes |
inventory_policy | No Type: string | Continue selling when out of stock
Deny: Does not continue selling when out of stock. |
images | No Type: array (string) | Variant image An array is sent containing the status, internal ID, and the image URL associated with each variant.
|
variant_alt | No Type: string | Alternative text of Variant Image. This field can be configured in two ways:
|
tracked | No Type: boolean / string | It defines whether an item's inventory should be tracked or not. This field should be matched with a text-type field with the values:
|
requires_shipping | No Type: boolean | True => This is a physical product, requires shipping field. Otherwise, False. In Shopify if no variants exist can be found in Shipping window within a variant. |
cost_per_item | No Type: float | Cost per Item field, near Price, indicating the cost of fabrication or similar
|
country_code_of_origin | No Type: string | Configurable attribute, region or country of origin for customs control. List of possible values at https://shopify.dev/api/storefront/reference/common-objects/countrycode |
province_code_of_origin | No Type: string | The ISO 3166-2 alpha-2 province code of where the item originated from. Link: ISO 3166-2 (example: ES-V, FR-IDF, etc.) |
harmonized_system_code | No Type: string | The harmonized system code of the item. |
countryHarmonizedSystemCodes | No Type: List | Same behaviour than fields: country_code_of_origin and harmonized_system_code |
weight | No Type: decimal | Weight, appears when the previous box is checked
*Does not work if the grams field is active |
weight_unit | No Type: string | Weight unit dropdown
*Does not work if the grams field is active |
inventory_quantity | No Type: number | Stock per variant, depending on the location. Implemented with InventorySetOnHandQuantitiesInput.setQuantities.quantity |
presentment_prices | No Type: table |
|
grams * | No Type: number | In version 1.9 is automatically converted to field weight, weight_unit. It is recommend to use weight_unit and set weight instead. (Does not work if fields weight, weight_unit are enabled) Weight (if it’s a physical product checkbox is true)
|
inventory management* | No Type: string | In version 1.9, the field inventory_management is automatically converted to field tracked but we do recommend using tracked. Next versions will not support inventory_management. Track quantity checkbox, mapped with the Inv Management field made specifically Configurable attribute:
Values:
|
fulfillment_service | No Type: string | In version v1.8: Location info, previously defined in Shopify. Defines the fulfillment service associated with the item. It should be mapped with a text-type field with the words:
In version 1.9, the connector does not implement fullfilment_service. |