Two sides of one application

DDM has a public face and a working face, and it is worth keeping them apart in your head. The public face — the demo gallery and the passport pages — is what consumers see when they scan a code; it needs no account, because a passport that required a login would defeat its purpose. The working face, everything behind Manage Data, is where your team curates the data. It always requires signing in, for two reasons: the catalog is tenant-scoped, meaning you only ever see and edit your own organization's records, and every change is recorded under the identity of the person who made it, so the version history can answer who changed what, when.

Signing in

Authentication is not handled by DDM itself but by your organization's central identity provider (Keycloak, via OpenID Connect). In practice this means you sign in with the same account you use elsewhere in your company, your administrator manages permissions in one place, and DDM never sees your password.

Open any catalog page and DDM sends you to the sign-in screen; after authentication you are returned exactly where you were headed — a deep link a colleague sent you survives the login detour.

Sessions expire eventually. When that happens mid-work, DDM shows a banner rather than throwing your work away: whatever you had typed stays in the form, and after logging in again you continue where you were. The sidebar footer holds the Log In / Log Out control and the light/dark mode toggle.

The catalog workspace

After signing in you land in the catalog workspace: a collapsible sidebar on the left, the working area on the right.

The sidebar's order roughly follows the life of a passport, and this guide follows it too. The first three entries — Products, Organizations, Places — are the catalog itself, the records you curate. The next two — Linksets and Domains — are the resolver side, where scans get routed. Field Access and Passport Templates hold the governance rules that shape both. Scan Analytics closes the loop with usage data, and Profile is about you and the systems acting on your behalf.

One design decision shapes how the whole workspace feels: there are no detail pages. Clicking a product does not navigate you away to a separate screen — it opens the record in a drawer over the list. Close the drawer and you are back exactly where you were: same search, same scroll position, same filters. When you work through twenty records in an afternoon, this is the difference between a flow and a fight. Deep links still work; every drawer state has a URL you can paste into a chat, and the recipient lands in the same record.

Finding things

Each list has a full-text search that covers all fields of the record, not just the visible columns — a search for a supplier's name finds the products referencing it even when no brand column is displayed.

The visible columns themselves are yours to shape. The column picker (next to Add Product) offers the core columns — name, identifier, access tier, brand — and beyond them every vocabulary term your records carry. If your team cares about, say, net weight and country of origin, put them in the table and the list becomes your working report. Selection, order and widths are remembered per list; Reset returns to the defaults.

And should a list ever refuse to load — a backend hiccup, a half-migrated tenant — Open by GTIN (or GLN) opens any record directly by its identifier. The list is a convenience; the identifier is the truth.

Your profile

Profile shows your account as the identity provider reports it — name, e-mail, and badges for the roles you hold — plus the credentials that let machines work with your catalog:

The integration tokens deserve a word of explanation. An external system — an ERP like Odoo, a warehouse middleware — should not log in with a person's username and password: passwords expire, people leave, and a shared password is an audit nightmare. Instead you issue the system its own long-lived token here. Name it after the system that uses it, and when that system is retired, revoke just its token — nothing else is affected. The token value is displayed exactly once at issue time and never stored in DDM; what remains visible is when each token was issued and last used, which is also how you spot a token that is no longer needed.

The two GS1 Germany cards on this page — the service token and the company-prefix pool — belong to outbound publishing and have their own chapter.

Access roles

Permissions in DDM are deliberately coarse: a handful of roles, assigned by your administrator in Keycloak, each unlocking one clear-cut area.

A page you are not entitled to does not greet you with an error code. It tells you, in a sentence, what is missing — "Scan Analytics requires the admin role" — so the conversation with your administrator is short.