What a linkset is

The QR code on a product is printed once and lives for years — on packaging in warehouses, on labels in stores, on products already in homes. Whatever it should lead to tomorrow must therefore be changeable without reprinting anything. That is the resolver's whole purpose: the code encodes only the product's identity, and the resolver keeps, for each identifier, the current list of destinations. This list is the linkset.

A linkset is more than one URL. Each destination is filed under a GS1 link type — a standardized answer to "what kind of information is this?": pip for the product information page, sustainabilityInfo for the sustainability report, instructions for usage instructions, traceability, certificationInfo, and dozens more. The types are what make the system machine-usable: a recycling app scanning your product does not guess its way through your links — it asks the resolver specifically for sustainabilityInfo and gets exactly that. One code on the packaging, many audiences, each routed to what they came for.

The Linksets page manages these lists — for any anchor, not just products: parties and locations (GLN), logistic units (SSCC), returnable assets (GRAI), and also anchors that have no master-data record at all. A pallet's SSCC can carry links without anyone creating a "pallet record" first.

Finding an anchor

The smart bar at the top takes whatever you have. Search by name, or paste an identifier in any form — a bare GTIN, a GLN, an SSCC, or a complete Digital Link URL copied from somewhere. DDM works out what you pasted, validates the check digit, shows existing linksets that match, and Resolve opens the explorer. For an anchor with no links yet, New linkset starts an empty one.

The explorer

At the top, the anchor card: the resolved Digital Link, how many relations it carries and how many links are yours to edit, along with Add link, Raw JSON (the linkset exactly as the resolver serves it, for the technically curious) and Export linkset. Below it, one card per link type, each listing its links with their file type, languages, and a Public/Private marker.

You will notice immediately that some links carry a lock and others do not. That distinction is the heart of this page.

Who owns a link

Remember that DDM derives things from master data wherever it can. Links are the clearest case: if the product record carries a product image and a certificate PDF, the resolver publishes links to them automatically — you never register them, and when the record changes, they change. The same goes for structural links the deployment provides, like the product information page. All of these appear in the explorer locked, because editing them by hand would be futile: the next master-data save would regenerate them.

But automation must never be a cage. Sometimes the generated link is exactly what you don't want — the sustainability link should point at this year's campaign page, not the PDF from the record. For that there is Take over:

Taking over a link type moves its links from the resolver's hands into yours: they stop updating on their own, and your changes stay. The explorer marks them Yours from then on. If you later regret it, Give back reverses the handover — the resolver fills the links in again, replacing your version. Both directions are explicit, both are labeled on the link, and nothing is ever lost silently: a locked link can always be complemented by adding your own link next to it, without taking anything over.

So when reading the explorer: a lock means "maintained for you, will regenerate", Yours means "maintained by you, will persist". Every badge has a help text saying exactly this in context.

Editing a link

Add link (or the pencil on any link that is yours) opens the link editor:

The required parts are simple: pick the link type, enter the target URL and a human-readable title. The picker carries the complete GS1 link-type registry — every standardized relation, searchable, each with its shortcode — so "which type is right for a care manual?" is answered by browsing, not by reading the standard:

The optional parts are what make a link good rather than merely functional. The file type tells a scanning application what the target returns — a web page, a PDF, an image — before it follows the link; a screen reader, a print dialog and a mobile app all benefit. The languages field lists which languages the target is available in, and the resolver then serves each scanner the best match for their device language — this is how a German consumer and a French one scan the same code and each land on instructions they can read. Public controls whether the link resolves anonymously, and the What gets saved preview shows the exact payload before you commit it.

Links that adapt to the scanned code

One product exists as thousands of items, and sometimes the destination should depend on which one was scanned — a warranty portal that wants the serial number, a recall checker that needs the lot. Registering a link per item is obviously absurd. Instead, a target URL can contain gaps that the scan fills in:

https://service.example.com/warranty{% if serial %}/{{ serial }}{% endif %}

When someone scans an item-level code (which carries the serial number), the gap is filled: …/warranty/SN-1234. When someone scans the model-level code (no serial), the optional part disappears cleanly: …/warranty. One link, correct for every code that can hit it.

You do not have to write these expressions by hand. The Insert an optional part button builds them, and the Try it out preview is a small sandbox: type what a scanned code might contain, clear a field to simulate a code without that value, and watch where people would land. The editor also warns — in plain language, not error codes — about the constructions that would misfire: a value already fixed by the identifier itself, a placeholder that can never be filled on this anchor, a part that would double a path segment. The preview always shows the real resolver result; when a warning and the preview seem to disagree, trust the preview.

The default link

One relation is special. defaultLink answers the most common request of all: a consumer scans the code with a stock camera app, which asks for nothing specific. Wherever defaultLink points, that is where they land. DDM pre-fills it with the product's passport page on this deployment — point it wherever your consumer experience lives.