All courses

Attributes and families

What attributes are, what families are for, and why they move the completeness number.

Video transcript

In this video, you'll create attributes and families, and see why they move completeness.

An attribute is a structured piece of product data, like color or material.

These two came in with your file, each with its values.

There are seven types: select, multi-select, yes or no, text, number, date and metric.

Create a size attribute, as a select…

…and add its values.

A family groups the attributes that apply to a type of product.

Create a Clothing family…

…check its attributes and which ones are required. That's how Bruxel knows what each product is missing.

On a T-shirt's record, assign its family.

Now Bruxel knows what it's missing: it has two of its three required attributes.

Fill in the size…

…and completeness goes up: brand, category, attributes and content add up to a hundred points.

And AI can fill in the attributes for you, on one product or many at once.

In the next video, you'll group a product's variants.

What an attribute is

A structured product fact — color, size, material — that feeds the description and your store filters. There are seven types:

List: one value from a closed set (color: red).
Multi-list: several values from the same set.
Yes/No.
Free text.
Number.
Date.
Measure: a number with a fixed unit (250 ml).

Families

A family groups the attributes that belong to a kind of product. A t-shirt and a backpack can share the color attribute, and each family decides whether it is required.

The family is what lets Bruxel know what a product is MISSING: without it there is nothing to compare against.

A category can carry a default family (in its detail, “Default family”): products without a family that enter it —or any of its subcategories, which inherit it as long as they do not declare their own— receive it in the same act. A family already set is never changed. For products that were already there, the category offers “Apply”, which leaves out those that sit in categories with different families. Deleting a family removes it from its categories; moving or deleting a category only changes what is assigned afterwards.

Groups: the sheet in sections

A group is a section of the product sheet —Master data, SAP, Merch, Ecomm— to split the work by team. Each attribute belongs to one group or to none; those without a group are shown last, under “Other”. The sheet and the grid order first by group and then by the attribute's order.

Groups are created and ordered on the attributes page, or with the “group” column of the definitions CSV, which creates the group if it does not exist. Which group each attribute belongs to is chosen on the attribute's page, and only an administrator can move it.

Removing a group deletes nothing: its attributes go back to “Other” and no value changes. The public API returns the group code on each attribute.

Shared value lists

When several attributes use the same values — the case color and the product color, the shades of two makeup lines — a list writes them once. You create it on the attributes page and each list attribute picks it on its own page, under “Shared list”.

When you link an attribute, the options it already had with the same text are linked (even if only upper/lower case differs), missing ones are created and its own options stay as they were. From then on, adding, renaming, translating or removing a value in the list changes every attribute that uses it, and each affected product gets a version in its history.

An option that comes from a list is edited in the list, not in the attribute. Removing a value from the list takes nothing away from a product: where a product uses it, it stays as the attribute's own option. Unlinking a list, or deleting it, doesn't delete options either.

How completeness is calculated

Each product adds up to 100 points across four parts:

Part	Points	How it fills up
Brand and category	25	Half for each one.
Attributes	25	Required attributes of its family that already have a value.
Content	35	Languages with a published description, out of the ones you configured.
Main image	15	A ready image on the product: the main one or, if you did not mark one, the first in the gallery. It is the one your store receives as the base image.

If a product has no family — or its family marks none as required — the 25 points are split across every attribute you defined in the catalog: filling half of them earns half the points.

Fill with AI

Instead of filling attribute by attribute, you can select products and have the AI complete them from what is already known about them. It costs credits and only charges for the ones it manages to fill.

The code in your store

Every attribute has a code in Bruxel, derived from its name. If your store (Adobe Commerce) knows it under a different attribute_code, enter it on the attribute page under “Code in your store”: the Adobe Commerce download CSV and the public API use that code as the column name, so your store's import finds the attribute without you renaming columns by hand.

It only allows letters, digits and underscore, and it cannot repeat across two attributes of your organization (they would be two identical columns). Leave it empty to go back to the Bruxel code. Column selections in Downloads and saved channels do not change: they keep using the code.

Import attributes from a CSV

If your attributes are already defined in a spreadsheet, you don't have to enter them one by one: under “Import attributes (CSV)” you upload a file with one row per attribute and Bruxel shows you what it would do before touching anything. The downloadable template has one example row per type.

Columns: code (optional; derived from the name when empty), name, type (select, multiselect, boolean, text, number, date, metric), unit (metric only), filterable (yes/no), external_code (the code in your store), values (separated by |, select and multiselect only) and label_en, label_fr, label_pt for the per-language labels. Headers accept upper case, accents and their Spanish names.
An attribute that already exists is recognized by its code and updated: name, filterable, code in your store, labels and new values. One that doesn't exist is created. Nothing is deleted: not attributes, not values missing from the file, not labels in other languages.
Whatever cannot be applied is reported per row with its reason (invalid type, missing unit, duplicate external code) and the other rows proceed. A type change that would leave inconsistent values is flagged and not applied.

Uploading the same file twice changes nothing: the second review says “no changes” on every row. Limit: 1 MB per file.

Rules for values

A select or text attribute can carry rules that run, in order, on every incoming value: convert a unit (number + unit → number × factor + another unit), replace one text with another, forbid a pattern or require one. The typical case: a size with ounces and milliliters mixed — with “convert oz → ml, factor 29.5735” a “1.7 OZ” enters as “50 ml”, and with “forbid oz” whatever could not be converted is rejected with the message you write.

Bruxel ships no conversion table: “oz” can be mass or volume, so you confirm the factor (shortcuts fill the form). Rules apply to what enters through the attributes page, the attributes import and the API. For what was already stored, “Review current values” shows what each value would become and “Apply” does it: if two options end up equal they are merged and their products move to the remaining one.

Patterns are bounded regular expressions: no repeated groups or backreferences, and they are measured on save; a pattern that is too expensive is rejected. Rules do not apply to numbers, measures, dates or yes/no, which already validate their shape.

Capture rules: when a field is required and where it comes from

Besides value rules, any attribute —of any type— can have capture rules. They are set up on its page, under «Rules», with attribute, structure and category pickers, and an operator or an administrator changes them:

Required when…: if the condition holds (for example, «imported or national» is Imported) and the field is empty, the product page warns next to the field and the import reports it row by row. It only warns: the product is saved and imported anyway.
Hidden when…: it is for the supplier onboarding form, which won't show the field while the condition holds. The product page and the grid always show it.
Derived from…: the system sets the value from a fixed value, another attribute (with a map: «when it is loyalty, set ZMYP; otherwise ZMOD»), a category code or a brand code. It can apply always or only when a condition holds.
Compare with another: on a number or a measurement, it warns when the comparison with another attribute doesn't hold (the sale price below the purchase price, the net weight above the gross weight).

Nobody types a derived attribute while its rule applies, not even the owner: the product page and the grid show it with a lock and the API answers that the system sets the value. It is recalculated on its own when its source is written, on import, when the product is categorized and when its brand changes, in the same history version as the change that moved it. A new rule, or a category or brand code that changed, doesn't rewrite what was already there: under «Rules», «Apply to existing products» counts how many products would change and applies them in rounds of a thousand.

An attribute has a single derivation, and a derived attribute is never the source or the condition of another one. When a derivation's condition stops holding, the value the rule set is removed and the field is free. Deleting an attribute or an option a rule names is rejected until it is removed from the rule; renaming them rewrites the rules on their own.

Convert a list into a measure

If a list's options are measures written as text (“50 ml”, “1.7 OZ”, “100 g”), “Convert to a measure” moves them to Measure attributes. From the list's detail, “Review the options” groups the options by the unit they carry and tells you how many products use each group; then you choose where each measure goes and confirm.

Each measure (volume, weight, length) goes to a measure attribute you already have or to a new one created on the spot. The number is stored converted to the destination's unit, rounded to 4 decimals.
“oz” can be volume (a perfume) or weight (a lipstick), and the list doesn't say which. You decide: send it to one of the two measures or leave it as it is; by default it stays. If your catalog has a column that tells products apart —the category, for example—, you can decide per value: fragrances to volume, lipsticks to weight.
Options that aren't a measure —no recognizable unit, or zero like “0.00 OZ”— aren't moved and are listed separately.

The list is kept with its options and products: the CSV that comes out of it today doesn't change until you change your channel's column. A product that already had a value in the destination keeps it. Every converted product is recorded in its history. Converting requires the operator role, and a protected destination, the administrator role.

Changing an attribute's code

The code is derived from the name when the attribute is created and is its identity from then on: it names the column in the Adobe Commerce CSV (when there is no code in your store), it is the source of your saved channels' columns and the route in the public API. That is why it could not be changed until now. From the attribute page, “Change code” shows you how it will be normalized, whether another attribute already uses it and which channels change their source, and only then you confirm.

Saved channels update on their own (their column points to the new code; the header you wrote does not change). What does NOT update on its own: integrations calling the public API with the old code get 404, and an attributes CSV carrying the old code would create a new attribute. Update those yourself.