---
title: "Organizations & Places"
description: "GLN-keyed party and location records in DDM — organization roles, primary locations, and the public GLN information pages."
canonical_url: "https://openepcis.io/docs/digital-data-management/organizations-and-places"
last_updated: "2026-08-26T20:11:04.617Z"
---

## Why products are not enough

A product passport keeps pointing beyond the product: *who* owns the brand, *who* manufactured it, *where* was it made, *where* does the recall notice go. If those answers were typed into each product as text, they would drift — three spellings of the same company, an address updated in some records and forgotten in others. DDM therefore treats parties and locations as records in their own right, with their own identifiers, referenced from products instead of repeated in them. Update the organization once, and every product pointing at it is current.

The identifier for both is the **Global Location Number (GLN)** — GS1's counterpart to the GTIN, a thirteen-digit key that can name a legal entity, a physical site, or even a digital location like an API endpoint. Because one number type covers both companies and warehouses, DDM splits the catalog into two lists that share almost everything else.

## Organizations

**Organizations** holds the parties: companies and organizational units. These are the records that a product's *brand owner* or *manufacturer* fields point at.

![The organizations list | Figure 1: The organization catalog — name, GLN, type and role at a glance](/img/13.Digital-Data-Management/organizations-list.png)

Beyond name and GLN, two fields carry most of the meaning. The **GLN type** says what kind of thing the number identifies — a fixed physical location, a mobile one, a digital location, a legal entity. The **organization role** says what the party *does* — brand owner, manufacturer, distributor — and is what makes references from products self-explanatory. Around them sit the practical details: localized names, postal address, contact points, and **primary locations** — references to the [places](#places) where the organization physically operates.

Editing happens in the same [passport editor](/docs/digital-data-management/passport-editor) as products, with everything that entails: generated form, live JSON-LD, version history, and GLN validation with its own length and check-digit rules.

![The organization editor | Figure 2: An organization in the passport editor](/img/13.Digital-Data-Management/organization-editor.png)

## Places

**Places** holds the physical counterpart: warehouses, factories, stores — locations with a GLN of their own.

![The places list | Figure 3: The places catalog](/img/13.Digital-Data-Management/places-list.png)

Places matter in two directions. Organizations reference them as primary locations. And [EPCIS capture](/docs/digital-data-management/passport-editor#epcis-capture-on-resolve) uses them as **read points** — when a scan on your domain generates a traceability event, a place record is what names *where* that happened.

One quirk of the GS1 data model is handled for you and only worth knowing so it never confuses you: in the vocabulary, a place's *name* lives inside its address block, and the GLN may be spelled under either of two field names depending on which system wrote the record. DDM reads both spellings, so a place created by another compliant application shows up correctly here.

## Public GLN pages

Like products, parties and locations have public faces, resolved through the same GS1 Digital Link machinery. The address encodes what kind of thing it identifies: `/414/{gln}` is a **location** page (GS1 Application Identifier 414 means "physical location"), `/417/{gln}` a **party** page (AI 417, "legal entity"). Scan a GLN barcode on a warehouse gate or follow a party link from a partner's document, and you land on the corresponding record — rendered, like every passport, through your [field-access policy](/docs/digital-data-management/field-access): public fields for everyone, the rest after sign-in.