Identifiers

An Identifier is the property that uniquely identifies an Item within a Level of a Table. See the Glossary for the general definition, and the Basics guide to learn how to declare them.

This page describes how the platform decides that two Identifier values are the same, which is what drives uniqueness errors, item matching during imports, and filtering.

Scope of the uniqueness constraint

An Identifier value must be unique:

• within a Table,
• for a given Level,
• for a given Identifier (each of the 5 Identifiers has its own, independent uniqueness constraint),
• across all Partitions of the Table.

Consequences

• Two Items in two different Partitions of the same Table and Level cannot share the same value for a given Identifier. Archiving an Item by moving it to another Partition does not free its Identifier value.
• The same value can be used on two different Identifiers (for example ABC on EAN_13 and ABC on SKU), on two different Levels, and in two different Tables.
• An Item can leave an Identifier empty, as long as at least one of its Identifiers is filled. Several Items can have the same Identifier left empty.

Format of a value

Rule	Behaviour
Maximum length	50 characters. A longer value is rejected (in the grid) or logged as an error (during an import).
Empty value	An Identifier cannot be saved with an empty value. To remove a value, delete the Identifier value explicitly - and at least one Identifier must remain filled on the Item.
Leading and trailing spaces	Removed before the value is saved. " REF-001 " is stored as "REF-001".

How two values are compared

Identifier values are compared in a way that is case-insensitive and accent-insensitive.

This is not a normalization of the value you store: the value is saved exactly as you typed it (accents and case are preserved and displayed). It is only the comparison between two values that ignores those differences.

Value already stored	Value you submit	Considered the same Item?
REF-001	ref-001	✅ Yes - case is ignored
Pôle qualité	Pole qualite	✅ Yes - accents and diacritics are ignored
Crème	CREME	✅ Yes - case and accents are ignored
REF-001	REF-001	✅ Yes - trailing spaces are ignored
Straße	Strase	✅ Yes - ß is compared as s
Straße	Strasse	❌ No - ß is not expanded into ss
Œuf	OEuf	❌ No - Œ is not expanded into OE (same for Æ / AE)
REF-001	REF001	❌ No - punctuation and spaces inside the value are significant
🍣	🍺	✅ Yes - see the warning below

Emoji and rare characters

All characters outside the most common Unicode range - emoji, and rare scripts or symbols - are compared as if they were one and the same character. Two Identifier values that differ only by such characters are therefore considered identical (🍣 and 🍺, for instance).

Emoji and symbols are not a sensible content for an Identifier: use plain letters, digits and punctuation.

Two visually identical values that are not considered equal

Some systems encode an accented letter as two characters (the base letter followed by a separate accent) instead of a single one. é written that way is not considered equal to é written as a single character, even though the two look strictly identical on screen.

If you paste Identifier values coming from an external system and end up with two Items that look like duplicates, this is the usual cause.

What it changes for you

In the grid

When you type an Identifier value that already exists on another Item - including with a different case or different accents - the modification is refused and an error message points at the conflicting Item. The value of the existing Item is left unchanged.

During an import

An imported line is matched against an existing Item using its Identifier values. A line carrying Pole qualite is therefore matched with the Item stored as Pôle qualité: the existing Item is updated, no new Item is created.

Do not rely on an import to correct the spelling of an Identifier

Because the incoming line matches the existing Item, its other values are updated as expected - but the spelling of the Identifier value itself is not guaranteed to be rewritten. To change the spelling of an Identifier value, edit it in the grid, or delete and recreate the Item.

If the imported line carries several Identifiers that match different existing Items, the import cannot resolve the conflict: the line is matched on the first filled Identifier, and the import then fails on the uniqueness constraint of the other one. Make sure each line is consistent with the data already in place.

When filtering and searching

Filters and searches on an Identifier follow the same rules - in the grid and through the Content Management API. Filtering on pole qualite returns the Item stored as Pôle qualité.

This applies to Identifiers only

Fields - including SINGLE-LINE-TEXT fields - are compared exactly: case, accents and every character are significant, both for filtering and for the value comparisons performed by Formulas, Mappings and Conditional formatting.

Do not assume that a value behaves the same way depending on whether it is stored in an Identifier or in a Field.

Recommendations

• Use Identifier values that are stable, technical and normalized upstream of Product-Live: uppercase letters, digits, and a simple separator (EAN_13, SKU-00123, …). Barcodes and internal codes are ideal.
• Avoid natural language as an Identifier value. If you need a readable label, store it in a SINGLE-LINE-TEXT Field next to a technical Identifier.
• If the values you receive are not guaranteed to be unique once case and accents are ignored, do not model them as an Identifier: use a SINGLE-LINE-TEXT Field instead.