Fields

Overview

In Supplier Data Manager (SDM), fields are the core data units of your project's data model — equivalent to product attributes in a PIM system. When configuring an SDM project, fields are the foundation: you can apply rules, warnings, and transformations to each field, and assign requirement levels to control how missing or invalid values are handled during the workflow.

Fields play a key role in the SDM workflow:

• Transformations modify raw field values (for example, trimming whitespace or converting text to uppercase).
• Rules validate field values and block the user from advancing if any rule fails. Multiple rules on the same field are combined with AND logic — all rules must pass.
• Warnings alert the user to potential issues but do not block progression to the next step.
• Requirement levels determine whether an empty field blocks the user (required), warns the user (important), or passes silently (optional).

The screenshot above shows the field configuration panel in SDM, displaying a list of fields with their associated rules, warnings, and transformations.

Configuration

Field configuration is managed at the project level in Supplier Data Manager. Go to Projects admin, select the right project, and then edit Fields.

The screenshot above shows the project admin screen in SDM with the Fields configuration section open.

Examples of fields with rules and transformations

The screenshot above shows a field (akeneo_onboarder_supplier_reference) configured with a max_length rule in the SDM field editor.

Example of a field (akeneo_onboarder_supplier_reference) with a max_length rule.

The screenshot above shows a field in SDM configured with a trim_whitespaces transformation, which removes leading and trailing spaces from the field value.

Example of a trim_whitespaces transformation declared on a field — it removes spaces at the beginning or end of the text.

Use cases

During the Normalisation step in Supplier Data Manager, SDM processes fields in the following order:

1. Validates that attributes have the correct type.
2. Checks that required fields are completed.
3. Applies transformations.
4. Evaluates rules and the requirement level.

Limitations & best practices

• Maximum number of fields: 12,000.

• Rules: Multiple rules on a field are combined with AND logic — every rule must pass for the field to be valid.
• Configuration complexity: Ensure that the combination of name and group is unique across the field configuration to avoid conflicts.

Groups

Overview

In Supplier Data Manager (SDM), groups organize fields based on conditions — comparable to product families in a PIM system. Groups let you define which fields apply to which products, and at what requirement level.

Each name/group combination can only be defined once across the fields in a project.

An important consequence of group conditions: one attribute can simultaneously be required in one group and optional in another for the same product. When an attribute matches multiple group conditions, SDM uses the first matching configuration in the list.

Configuration

Group configuration is managed at the project level in Supplier Data Manager. Go to Projects admin, select the right project, and then edit Groups.

Administrators define groups by specifying a name, label, and conditions for each group. Here is an example:

{
    "name": "Aquatic_Reptile_Bedding_Substrate",
    "label": {
      "en-US": "Aquatic & Reptile Bedding/Substrate"
    },
    "conditions": [
      {
        "name": "required",
        "field": "family",
        "negate": false
      },
      {
        "name": "isin",
        "field": "family",
        "negate": false,
        "values": [
          "Aquatic_Reptile_Bedding_Substrate"
        ]
      }
    ]
}

• The conditions determine which fields belong to a group. If no conditions are provided, the group applies to all attributes.
• A product can belong to multiple groups, but a unique combination of group name and field name is required.

When a field matches multiple group conditions, SDM selects the first matching entry in the configuration. In the example below, a t-shirt product belongs to groups g1 and g3. Because the color field appears in both g1 (required) and g3 (optional), SDM uses the first match — g1 — so the effective requirement level is required:

Examples of group configurations

The screenshot above shows an example group configuration in the SDM project admin panel, with group name, label, and conditions defined.

The screenshot above shows a second example of SDM group configuration with multiple conditions specified.

Use cases

• Managing product families: Organize product attributes into groups to ensure consistent data management across products. For example, an electronics product family could include groups like "Battery" and "Hardware".
• Handling select options per group: Use different groups to manage different select option values for the same field across product types.

Limitations & best practices

• Keep group conditions simple: Avoid complex condition combinations that could cause a field to match multiple groups ambiguously — SDM always selects the first match.

Display groups

Overview

In Supplier Data Manager (SDM), display groups are a UI-only concept that bundles fields together for easier navigation in the interface. Unlike groups (which control data logic and conditions), display groups have no effect on validation or data processing — they exist purely to improve the user experience.

Each display group has a name, a label, and a list of fields. A field can belong to only one display group at a time.

Configuration

Display group configuration is managed at the project level in Supplier Data Manager. Go to Projects admin, select the right project, and then edit Display Groups.

The screenshot above shows the Display Groups configuration section in the SDM project admin panel, with a list of named groups and their associated fields.

Administrators define display groups by specifying a name, label, and a list of fields that belong to the group. Here is an example:

{
  "name": "Pricing",
  "label": {
    "en-US": "Pricing"
  },
  "fields": [
    "price",
    "currency"
  ]
}

Interface

Display groups are visible to users in the following SDM modules: Mapping, Value Mapping, Normalisation, and Extraction. Fields are shown bundled under their display group label, with localized labels displayed in the user's selected catalog language.

The screenshot above shows display groups as they appear to users in the SDM interface, with fields organized under labeled group headings.

Use cases

• Simplifying UI navigation: Group related fields — such as "Price" and "Discount" — into a single display group so users can find and edit them more efficiently.
• Managing product families: Mirror your product family structure in display groups to make large field sets easier to navigate.

Limitations & best practices

• A field can belong to only one display group. Plan your groupings carefully to avoid leaving fields ungrouped or grouped ambiguously.
• Use display groups strategically in large data sets where field organization can otherwise become overwhelming.

Available Locales

Overview

In Supplier Data Manager (SDM), available locales define which languages can be selected when viewing and editing data within a job. This is distinct from the SDM interface language (which supports English and French only), and controls the language used to display field names, labels, and option values throughout the workflow.

Available locales are configured at the project level. The locales defined here must match the localized labels for fields, groups, and options in the frontend configuration.

Configuration

Available locale configuration is managed at the project level in Supplier Data Manager. Go to Projects admin, select the right project, and then edit Available Locales.

The screenshot above shows the Available Locales configuration section in the SDM project admin panel, listing the locales enabled for the project.

Interface

If your product catalog has translated fields, users can switch the catalog display language directly from the job page by changing the Catalog language setting. This option is available at any step of a job.

For example: if your team is based in China and works on a specific workflow, they can apply the zh_CN locale, which immediately translates field names across all steps.

Both SDM operators and suppliers using Supplier Access can switch the catalog language while working on a job.

The screenshot above shows the Catalog language selector in an SDM job, allowing users to switch the display locale for field names and labels.

Use cases

• Multi-language teams: Support projects with multiple locales so each team member can work in their preferred language while the interface language remains consistent.

Limitations & best practices

• Locale matching: Locales configured in the project must match exactly with the localized labels defined for fields, groups, and options. Any mismatch results in missing or incorrect labels.
• Regular locale audits: Verify that all available locales have corresponding localized labels in the configuration to prevent missing translations.