Dependency Overview

Dependency is a feature designed to maintain high product data quality and governance by guiding users through the product enrichment process.

It allows you to establish relationships between product attributes and properties, making data input more efficient and accurate. These dependencies will serve as additional rules that attributes must comply with, ensuring a robust data model. Product completeness will also account for these rules, ensuring relevance and actionable insights.

With Dependency, you can configure the product enrichment process based on specific parameters (such as attribute values, families, or categories), enabling you to:

• Control the visibility and display of attributes based on conditional logic.
• Allow or restrict the enrichment of specific attributes and compute completeness accordingly.
• Restrict the list of allowed values for an attribute based on specific conditions.

Create and enable a dependency

To create a dependency:

1. Go to “Settings”
2. Click on “Dependency”
3. Click on create and fill in a label for your dependency
4. Click “Save”
5. Define your dependency structure (see below)
6. Click “Save and Enable” to enable the dependency in the PIM. Or Click “Save as draft” to save your changes without enabling the dependency.

Define your dependency structure

By creating a new dependency and navigating to the "Dependency" tab, you can start defining it.

1. The product selection
2. The triggering attributes (optional with the action ‘allowed values’)
3. The dependent attribute and their expected behavior

Product Selection

The product selection defines the set of products that will be impacted by the dependency once it's enabled. The impacted products will be subject to the specific behaviors set in the “Apply dependency” section.

You can build a product selection by filtering on the family and/or categories properties of the products.

Triggering Attributes

The configuration of triggering attributes allows you to set up conditions for the dependency to be triggered on the product. To set it up, you can choose an attribute and select the value(s) for which the dependency should be activated.

The attribute types supported as a triggering attributes are: boolean, simple select, multi select, reference entity single link and reference entity multiple links.

Apply dependency

In this section, you can select one or several attributes and define the behavior you want by choosing an appropriate action for each.

The type of actions you will be able to setup will depend on the attribute type of a dependent attribute.

- The action Is Displayed

• If the configuration for the dependent attribute is met and the action is “Is Displayed”, then the product value will be available for enrichment and displayed in the product edit form (given the attribute is set in the attribute’s family)
   
• If the configuration of the triggering attribute is not met and the action is “Is Displayed”: The product value won’t be available for enrichment and will be hidden from the product edit form and excluded from the completeness calculation (even if it is part of the family and defined as required for the completeness on any channel). 

  Please note that, if the condition on the triggering attribute is not met, any attempt to fill the value through import or API will be forbidden and a validation error will be thrown. 

   
  
   

Sample use case with “Is Displayed”: The “Food certificate”

The dependency we want to set up is the following: “For all Food products that are produced in Germany, a certificate has to be filled in.”

Given we have a “Food” family with 2 attributes required for completeness and a “Salmon” product.

• “Origin”: Country of origin (Simple select attribute type)
• “Certificate”: File for the certificate (File attribute type)

Here is a screenshot of the family configuration and the attribute requirements for the “Food” family.

To set up such dependency in the PIM, we can create a new dependency which will impact products in the “Food” family and:

• Set up “Origin” as a triggering attribute so it activates for the “Germany” option.
• Set up the “Certificate” attribute as a dependent attribute with action: “Is Displayed”.

Here is how the “Food certificate” Dependency would look like:

Here is how the “Certificate” attribute will behave depending on the “Origin” attribute:

• If the “Origin” attribute is filled with option “Germany”, then the “Certificate” attribute shows up.
• If the “Origin” attribute is filled with option “France”, then the “Certificate” attribute is hidden.

Impacts of the “Is Displayed” action on the completeness

Let’s observe how the completeness is dynamically calculated to take into account the dependency, as this product page gets filled with different values for the triggering and dependent attributes.

• Here is an example of the completeness for a product with an empty value on the triggering attribute “Origin”.
  • The completeness is at 50%.
  • The dependent attribute is hidden.

• Here is the completeness for a product with a value different from “Germany” in the “Origin” attribute:
  • The completeness is 100%
  • The dependent attribute remains hidden

• Here is the completeness for a product with origin “Germany” but without a certificate filled in.
  • The completeness is 66%
  • The dependent attribute is now displayed

• Here is the completeness for a Food product with origin “Germany” alongside it’s certificate.
  • The completeness is 100%.
  • The dependent attribute is now displayed.

- The action: Allowed values

This ensures that users see only the relevant options when the dependencies are triggered, streamlining data selection and validation.

By selecting this action, you can define a list of available options. You will then be able to use any options from the list to enrich the attributes of products that meet the dependency requirements.

Here is an example showcasing the list of options (Battery type = ‘AA’; ‘AAA’; ‘AAAA’) we selected which need to appear in the Product Edit Form. Other options such as ‘Built-in rechargeable’ or ‘9V’ do not match wit the ‘Camera’ family.

In the Product Edit Form, if the attribute ‘Battery Operated’ is ‘YES’, the attribute ‘Battery type’ will only show the pre-filtered choices ‘AA’; ‘AAA’; ‘AAAA’.

Conflict management

When building a dependency, you might encounter cases where existing values within your products do not comply with it. This is known as a conflict.

The PIM helps you resolve these conflicts effectively by providing a list of conflicting products and offering user actions to address them.

Conflicts overview

By navigating to the “Conflicts” tab of your dependency, you get access to the list of products conflicting with your rule. You can filter these products based on the dependent attributes set up.

The "Conflicts" tab also shows the total number of conflicts between your dependency and your entire product catalog.

When the PIM detects a conflict with a dependent attribute, it will display a warning icon next to it. Clicking on the warning icon will take you to the conflict grid and filter the conflicts for that specific dependent attribute.

Resolving conflicts

The PIM gives you the ability to review the values that might be in conflict with the existing dependency in the ‘Conflicts’ tab.

Updating a conflicting product value

If a product value is in conflict with a dependency, it will not be possible to update the product value in a way that does not comply with the dependency setup in your PIM.

Regarding product updates when there is a conflict:

• If a product has a conflict, you will be able to update the product if you modify another attribute that is not included in your dependency. 
• But if a product model has a conflict, you will not be able to update the product before solving the conflicting value.

Exporting a conflicting product value

If a product value is in conflict with a dependency, the conflicting value will be exported through product exports and product API endpoints.

The value will also be displayed in the Product Edit Form with a message underneath explaining that this value is in conflict with a dependency as shown below:

Preventing conflicts with the catalog

Since your catalog is likely to evolve over time and could potentially create conflicts with existing dependencies, we’ve outlined all possible use cases and their consequences.

What happens if you:

Manage permissions

By default, all users have the right to view the dependency in the Product Edit Form and the ‘Dependency’ section in the Settings.

If a user has the right to ‘Edit an attribute’, he/she will be able to create, modify and delete a dependency. 

A few examples of use cases 
 

For conditional attributes

Let’s imagine we have a PIM catalog set up with the following:

• A product in Camera family
• With attribute Battery operated equal to true
• And attribute Battery type with the action ‘is displayed’

This dependency applies to products in the Camera family.

• For products where the attribute battery operated is set to true:
  • The battery type attribute will be displayed on the Product Edit Form.
• For products where the attribute battery operated is not true:
  • The battery type attribute will not be displayed on the Product Edit Form.
     

For conditional Values

This dependency applies to products in the Shoes family.

• The options available in the size attribute are filtered to show only '38', ’39‘, ‘40, ‘41, ‘42’, ‘43’, and will be displayed accordingly in the Product Edit Form.
• If the ‘Gender’ selected on the Product Edit Form is not ‘Women’, then the ‘Gender’ attribute is still shown, but it will display all existing options that were set up for this attribute.