Soon-to-be released
Our new feature Dependency is not available yet but will be released very soon - stay tuned!
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:
- Go to “Settings”
- Click on “Dependency”
- Click on create and fill in a label for your dependency
- Click “Save”
- Define your dependency structure (see below)
- 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.
- The product selection
- The triggering attributes (optional)
- 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
.
Limitations
- Localizable and scopable attributes cannot be set as triggering attributes.
- There can only be 1 triggering attribute per dependency.
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.
You can select all attribute types (expect identifiers) as dependent attributes.
- The action Is Displayed
All attribute types (except identifiers) can be selected as dependent attributes with 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.
As you will see below and for each case, the completeness score becomes dynamic as its calculated to take into account the dependency and the values that have to be filled in.
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.
This action is available for Simple select
, Multi select
, Reference entity single link
and Reference entity multiple links
attribute types.
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’.
Important information
- Attempting to enrich an attribute with a value that is not on this list will result in a validation error on imports, or API endpoints
- The list of options available in the PEF will only show options valid in regard to the dependency.
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 rule 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.
Trying to update the product via import jobs, API or PEF will result in a validation error thrown by the PIM.
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:
Action | Outcome | |
---|---|---|
Delete a triggering attribute configured in the dependency |
|
The dependency needs to be disabled before you remove the attribute. |
Delete a dependent attribute configured in the dependency |
|
The dependency will still work. |
Delete an attribute from a family not configured in the product selection of the dependency |
|
The dependency will still work. |
Modify the family of an existing product |
|
The dependency will not be applied for this product. |
Delete an option or record in a dependent attribute with the action 'is filtered with': |
- If some options remain |
The dependency will still work. |
- If no options or records are left |
The dependency will still work, but no options will be selectable. |
|
Delete an option or record in a triggering attribute with the action 'is filtered with' |
|
The dependency will still work. |
Delete an option or record in a triggering attribute with the action 'is displayed' |
|
A conflict will be created. Conflicts can be managed in the 'Conflicts' tab of each dependency. |
Delete a family or category from the product selection of the dependency |
- If some families or categories remain selected |
The dependency will still work. A warning symbol will appear, indicating that some families or categories are no longer present. You must remove non-existent values to save the dependency. The dependency will apply to the new product selection values. |
- If no families nor categories remain selected |
The dependency will not be applied. |
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
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 in the product edit form
- The
- For products where the attribute battery operated is not true:
- The
battery type
attribute will not be displayed in the product edit form, and the completeness calculation will not take it into account
- The
For conditional Values
This dependency applies to products in the Shoes
family.
- The options available in the
size
attribute are filtered to show only ‘37’, '38', ’39‘, ‘40 and will be displayed accordingly in the Product Edit Form, if the value ‘Women’ is selected for the attribute ‘Gender’.
Limits of dependencies
Please note that you can create up to 100 dependencies.