Overview

The Mapping step in Supplier Data Manager (SDM) aligns incoming supplier data with your internal attribute structure. It lets you map source columns from supplier files to the destination fields defined in your project taxonomy.

Configuration

The SDM Mapping step accepts the following configuration parameters:

• fields — Override project fields. The properties below apply to each Field object in the mapping configuration:

  • mode — What to do when mapping multiple source columns to a single field:
    • join — Join them using a separator
    • first — Use the first non-empty value
  • protected bool (default: false) — Prevents the user from modifying the field in the UI. Useful when assigning a default value in the configuration. For example, if the product name must always be a concatenation of brand and product title, set protected: true so the user cannot override it.
  • default — Assign default values to columns when no value is present:
    • type:
      • constant — A hard-coded value is populated in the output column
      • column — Read values from another column
      • metadata — Read metadata such as the job creator name or portal name
    • column — The field value from the job (e.g. ean, sku) when type=column
    • constant — The hard-coded content when type=constant
    • metadata — The metadata source when type=metadata
  • editable_default — Only used when default.type=constant. Adds an input field to the mapping UI that allows users to modify the default value at runtime.

• include_fields — Use only these fields from the project. See Normalization — field inclusion/exclusion.

• exclude_fields — Use all fields in the project except those in this group. See Normalization — field inclusion/exclusion.
• groups — Same as in the Normalization step.
• max_requirement_level — See the detailed explanation.
• default_join_separator — The separator used when multiple source columns are concatenated into a single field.
• block_learning bool (default: false) — When set to true, prevents SDM from saving mapping results to memory. Set this to true in demo environments to avoid polluting mapping memory between demo runs.
• dont_use_groups bool (default: false) — When set to true, each field appears only once in the mapping interface regardless of how many groups it belongs to, and a single unified mapping applies across all groups. This eliminates repetitive mapping in projects where the same field belongs to many families. See Mapping without groups for configuration details and workflow examples.

Op status mapping

The SDM Mapping step records the following operational status for each mapping run:

• stats — Summary statistics for the mapping run
• original mapping — The mapping SDM suggested automatically
• user mapping — Adjustments made by the user after the automatic suggestion

This audit trail is useful for diagnosing issues when a customer reports unexpected mapping behavior.

Mapping results

The screenshot above shows the SDM mapping results table with four columns: old (source column name as it appears in the input file), group (the field group), counter (number of times this mapping has been used), and new (destination field name).

• old — The field name as it appears in the source file
• group — The group the destination field belongs to
• counter — How many times this mapping has been applied
• new — The destination field name

Interface

The SDM Mapping step interface displays destination attributes organized by Display Groups, such as "Main Attributes" and "Other Attributes."

The screenshot above shows the SDM Mapping interface. Fields are grouped by Display Group. Visual indicators show which fields are required (red asterisk), mapped (green checkmark), or optional (gray bubble).

You can map multiple source columns to a single destination attribute using one of two modes:

• Concatenation logic (join) — Combine columns using the default_join_separator.
• Selection logic (first) — Use the first non-empty value from the selected columns.

For more information on Display Groups, see Fields, Groups, Display Groups & Available Locales.

The Unmapped fields only option is enabled by default, allowing users to focus on new or unrecognized fields. SDM's mapping memory tracks how often a given source column has been mapped to each destination field and automatically prioritizes the most frequently used matches.

Example: If product name has been mapped to name 100 times and nom mapped to name 90 times, SDM prioritizes product name for future files that contain both columns.

AI-powered mapping suggestions

SDM includes AI-powered mapping suggestions that automatically propose source column matches for unmapped fields. When users click Generate AI mapping, the AI analyzes:

• Column names from the source file
• Sample values from each column
• Target field names, types, and descriptions from the taxonomy

Each suggestion includes a confidence score (0–100%). Only suggestions with a confidence of 70% or above are surfaced. Already-mapped fields are left untouched.

Limitation: AI-powered mapping supports source files with up to 2,000 columns. Files exceeding this limit require manual mapping.

Mapping memory management

Every time a mapping job runs in SDM, the mapping results are saved for future reuse. As an organization admin, you can manage this mapping memory by going to Project > Settings > Steps, then selecting your Mapping step.

From this panel you can:

• Bulk update mapping pairs
• Delete a specific mapping pair that is no longer valid
• Clear all mapping memory — useful when setting up a project for the first time or resetting a demo environment

The screenshot above shows the SDM mapping memory management panel, accessible from Project > Settings > Steps. It lists each saved mapping pair (source column → destination field) with options to update individual entries, delete specific pairs, or clear all memory at once.

Use cases

• Structuring supplier catalogs — Align supplier data formats with your internal taxonomy.
• Concatenating fields — Combine values from multiple source columns (e.g., joining brand and product title into a single name field).
• Transforming data — Modify values during mapping, such as converting text to uppercase.
• Filtering previously imported products — Use a SKU or combination of identifier columns to distinguish new products from updates, so that SDM only processes new products.

Example and recipes

Filter out products previously imported

A common use case is to use SDM only for creating new products, not for updating existing ones. To do this, identify products by a unique key such as the SKU (or a combination of columns such as supplier name and supplier reference).

Use a Reference Base to store the known products. SDM can then compare incoming data against this Reference Base to filter out products that already exist before they proceed further in the workflow.

Limitations and known issues

Legacy field grouping: Fields are organized into main_attributes and other_attributes by default — a legacy structure that reduces flexibility in customization. For family-aware workflows, use dont_use_groups: true combined with the Mapping without groups approach.

Mapping per field × group: In the default (group-aware) mode, mapping must be defined for each combination of field and group, not per field alone. See Mapping without groups for an alternative.

No advanced transformations in configuration: Advanced transformations (e.g., concatenation, uppercasing) cannot be applied directly within the Mapping step configuration.

Workflow ordering: Each workflow must begin with a Mapping step. Skipping or reordering this step is not supported.

Front-end performance in large projects: Front-end performance degrades in projects with more than approximately 2,500 fields, depending on the user's machine. This is most noticeable when filtering or searching fields in the mapping interface.