Fields

Overview

Fields are attributes in your data model. When beginning the SDM configuration, it's important to understand that you can use rules, warnings, and transformations, as well as assign requirement levels to specific fields if you want additional checks on your data values during your workflow.

Fields plays a key role in transforming the data (cf Transformations), applying a list of rules to ensure the correctness of data, a list of warnings to warn the user of incorrect data and finally a requirement level to define if it’s required (a blocker at UI level for the end user), important (end user is warned but can skip) or optional (end user isn’t warned nor blocked).

Configuration

Configuration of the fields is at the project level. Go to Projects admin, select the right project, and then edit you can edit Fields.

Examples of Fields with Rules and Transformations

Example of a field (akeneo_onboarder_supplier_reference) with a rule max_length

Example of a transformation declared on a Field with trim_whitespaces . It removes spaces at the beginning or the end of the text.

Use cases

For example at the Normalization steps, depending on your field configuration, SDM will check following this order if:

1. attributes have the right type
2. what should be completed is
3. transformations have run
4. rules and requirement level are respected

Limitations & Best Practices

• Maximum number of fields: 12 000

Please note that you still might experience performance issues with the interface at this maximum.

• Rules: If multiple rules are on a field, they are combined with an “AND” operator. So it’s a combination of all rules, in other words, all rules must be valid.
• Configuration complexity: Administrators must ensure that the combination of name/group for fields is unique across the configuration to avoid conflicts.

Groups

Overview

Comparable to "families" in Product Information Management (PIM) systems, groups organize fields based on certain rules. Each name/group combination can only be defined once in the fields.

One attribute can be required and optional at the same time for the same product.

Configuration

Configuration of the groups is at the project level. Go to Projects admin, select the right project, and then edit you can 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 is valid for all attributes.
• A product can be part of multiple groups, but a unique combination of group name and field name is required. When an attribute matches multiple group conditions, the first matching attribute in the configuration will be selected. In the following case, we will keep the requirement level required.

Examples of Group configurations

Use cases

• Managing Product Families: Organizing product attributes into groups to ensure consistent data management across products. For example, an electronic product family could include groups like “Battery” and “Hardware”
• Can help handle different select options if different groups

Limitations & Best Practices

• Simplify group rules: Keep the group conditions simple to avoid conflicts where a field might fit into multiple groups.

Display Groups

Overview

These are designed for UI purposes, grouping fields to simplify the user experience. Each display group has a label and fields associated with it.

Configuration

Configuration of the display groups are at the project level. Go to Projects admin, select the right project and then edit you can edit Display Groups.

Administrators define display groups by specifying a name, label, and a list of fields that belong to that group. A field can only exist in one display group at a time. Here is an example:

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

Interface

Display groups are only for UI display purposes, offering a way to group fields for ease of access in the frontend, especially in the following modules: Mapping, Value mapping, Normalisation and Extraction.

Users see display groups of fields bundled together with localized labels, making it easier to navigate and interact with the data in their preferred language.

Use cases

• Simplifying UI Display: Using display groups to bundle related fields for easier navigation and input, such as grouping “Price” and “Discount” fields in a single section for ease of editing.
• Managing Product Families: Organizing product attributes into groups to ensure consistent data management across products. For example, an electronic product family could include groups like “Battery” and “Hardware”
• PIM connection: The SDM system will automatically retrieve the Attribute groups from the PIM and display them as “display groups” in all related modules.

Limitations & Best Practices

• UI customization: Use display groups strategically to enhance the user experience, particularly in large data sets where field organization can become overwhelming.

Available Locales

Overview

The user can choose the locale they want to display from a job that has already started, depending on the locales available at the field level. This is distinct from the user interface language, which currently only offers translation of the SDM interface into French or English.

Configuration

Configuration of the available locales is at the project level. Go to Projects admin, select the right project and then edit you can edit Available Locales.

Projects can be configured to support multiple languages through available locales. The locales must match the localized labels for the fields, groups and options is managed in the frontend configuration.

Interface

If your product catalog has translated fields, then you can set up a specific translation for your SDM interface from your job page.

Ex: you have a team based in China and they are working on a specific workflow, then they can apply the local CN during their job, which will immediately translate the fields names in all steps.

Users, from SDM and SDM Supplier Access can switch the language of the fields while working on a job. By switching the Catalog language :

Available in any step of a job.

Use cases

• Multi-language Localization: Supporting projects with multiple locales by displaying the appropriate localized labels and descriptions based on the user’s selected language while keeping the interface language consistent.

Limitations & Best Practices

• Locale Matching: Locales in the project must match exactly with the localized labels to ensure the correct data is displayed. Any mismatch can lead to missing or incorrect labels being shown.
• Regular locale audits: Ensure that all available locales have corresponding localized labels in the configuration to prevent missing translations.