Mapping

Summary

Overview

The mapping step ensures that incoming data, whether from suppliers or other systems, is accurately organized according to the expected structure. It allows the user to map the source columns of the input to the attribute list of the destination.

Once a mapping is completed, SDM remembers the configuration and automatically suggests the same mapping for future jobs.

 

Configuration

Always be sure to refer to the API docs. The API docs are always up to date and should remain a source of truth. It is recommended to double-check the info presented here against it (and update it if not up-to-date).

 

Below are some key parameters specific to the Mapping configuration:

  • fields - override of project fields. The properties below are specific to the Field object in the mapping config:
    • mode what to do when mapping multiple columns into a single field
      • join - join them with a separator
      • first - use the first non empty value
    • protected bool(False) - prevent the user from modifying the field in the UI. Useful when assigning a default in the config. For example, the client has a rule that says the product name is the brand - product name. We create the field by concatenating the two fields. Protected true will ensure that the user cannot do anything.
    • default: can assign default values to the columns if there is no value
      • type:
        • constant a hard coded value will be populated in the output column
        • column: if we want to read values from a column
        • metadata rarely used, can be used to input metadata such as job creator name or portal name
      • column: the value of a field from the job (e.g. ean, sku… ) when type=column
      • constant: the value of the hard coded content when type=constant
      • metadata: the source of the metadata when type=metadata
    • editable_default: only used when default.type=constant. Adds an input field to the mapping UI that allows dynamically modifying the default value.
  • include_fields - Use only these fields from the project - See Normalization#include_exclude
  • exclude_fields - Use all fields in the project except the ones in this group - See Normalization#include_exclude
  • groups: same as in the Normalization step
  • max_requirement_level: see the detailed explanation
  • Specific mapping options
    • default_join_separator: If we select multiple source columns, how will we concatenate them.
    • block_learning: Prevents saving the mappings for the demo because otherwise, we would have problems for the next demo (rename to block_learning_demo?). False by default.

Op Status Mapping

  • stats
  • original mapping: what SDM mapped automatically
  • user mapping: what the user mapped afterwards

This information will be particularly useful to retrace the events in case the customer has issues/complains.

Mapping results

  • old: field as it is entered in the source file.
  • group: of the new field.
  • counter: how many times this mapping was done.
  • new: destination field.

Use Cases

  • Structuring Supplier Catalogs: Mapping helps format supplier catalogs to align with your internal system’s expectations.
  • Concatenating Fields: Combine values from multiple fields (e.g., joining product names and brands).
  • Transforming Data: Modify data by converting it to uppercase or applying other transformations.

Interface

The attributes are grouped by Display Groups, such as "Main Attributes" and "Other Attributes." 

You can map multiple source columns to a single destination attribute by applying either:

  • Concatenation Logic: Combine columns with a separator.
  • Selection Logic: Choose the first non-empty column.

(More information on Display Groups: Fields, Groups, Display Groups & Available Locales)

Important fields are treated as optional in this module to display only the "required" and "optional" attributes to the user.

 

The “Unmapped fields only” option is enabled by default, allowing users to focus on mapping new fields. SDM’s memory tracks how often specific source columns are mapped to a destination attribute, automatically favoring the most frequently mapped columns.

Example: If “product name” has been mapped to “name” 100 times and “nom” mapped to “name” 90 times, SDM will prioritize mapping “product name” in future files that contain both columns.

Limitations and Known Issues

Legacy Field Grouping:
Fields are organized into "main_attributes" and "other_attributes," a legacy structure that reduces flexibility in customization.

Mapping by Field x Group:
Mapping must be defined for each combination of field and group, rather than per field alone. (See Groups for details.)

No Advanced Transformations:
It is not possible to apply advanced transformations (e.g., concatenation or uppercasing) directly within the Mapping step configuration.

Configuration Example – activite_animal:
When defining "main_attributes" or "other_attributes" groups in the configuration, it’s necessary to account for their exclusion at the Normalization and Extraction steps.

Workflow Automation:
Each workflow should always begin automatically with a Mapping step, without the option to skip or reorder it.

Performance Constraints in Large Projects:
Front-end performance degrades in projects with a large number of fields. This is particularly noticeable in filtering, searching, or interacting with projects containing over 2,500 fields, depending on the end user's machine specifications.