---
title: "Field Access Control"
description: "Deciding which data fields consumers, operators and authorities can see — tier by tier, with persona preview and a reviewer workflow."
canonical_url: "https://openepcis.io/docs/digital-data-management/field-access"
last_updated: "2026-08-26T20:11:08.338Z"
---

## The problem this page solves

A digital product passport puts more product data on the open web than most companies have ever published — and that is precisely its tension. The product name belongs to the world. The gross weight is useful to logistics partners and noise to consumers. The manufacturing site can be commercially sensitive, or even a security concern, and belongs only in front of authorities. A passport that showed everything to everyone would either leak or, more likely, never get filled with the sensitive fields at all.

**Field Access** resolves the tension by making visibility a property of the *field*, not of the page. Every vocabulary term carries one of three tiers, and every consumer of the data — the [passport page](/docs/digital-data-management/public-passports), the API, the editor — honors the same tiering:

<table>
<thead>
  <tr>
    <th>
      Tier
    </th>
    
    <th>
      Who sees the value
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Public
      </strong>
    </td>
    
    <td>
      Everyone, anonymously
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Authorized only
      </strong>
    </td>
    
    <td>
      Signed-in users of your tenant
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Restricted
      </strong>
    </td>
    
    <td>
      Holders of the <code>
        dpp-restricted
      </code>
      
       role — typically authorities
    </td>
  </tr>
</tbody>
</table>

The result, seen from the outside: one printed QR code, one address, and three different pages depending on who is asking. Seen from the inside: data entry without a nagging worry, because the person filling in the manufacturing site knows the tier travels with the field.

Like [passport templates](/docs/digital-data-management/passport-templates), the policy is layered — annotated defaults ship with the vocabulary, a deployment can adjust them, a tenant can adjust them again — and only differences are stored, so vocabulary updates never wipe your decisions.

## The access matrix

![The field access matrix | Figure 1: One row per term — shipped default, effective tier, and status badges for mandated and overridden fields](/img/13.Digital-Data-Management/field-access-matrix.png)

Pick the **vocabulary** and **resource type**, and the matrix lists every term with its shipped **default** and its **effective tier** — the three-state control you actually operate. Changing a tier marks the row *Modified* with the scope of the override; *Reset to default* takes it away again. A field with no tier of its own shows *inherited*: it follows the field that embeds it, so an address block's street does not need its own decision.

Some rows will not let you loosen them, and the badge explains why: **Mandated** tiers come from regulation — *ESPR Annex III* says certain data points are public, full stop — and DDM refuses overrides that would fall below the mandate. The refusal is not a permissions quirk; it is the regulation showing through the tool.

The **scope** selector switches between the deployment default and a tenant's override layer. **Sync schema** pulls the current annotated vocabulary, and the displayed schema version tells you which state of the world the matrix is arguing about.

## Persona preview

Tier-by-tier reasoning is abstract; what people actually want to know is *"what does a consumer get?"*. **Preview as** answers it directly: pick *Consumer*, *Operator* or *Authority*, and the matrix re-renders through that persona's eyes, showing exactly the fields that audience receives. It is the recommended last step before publishing a policy change — cheaper than discovering the answer on the live passport.

![The consumer persona preview | Figure 2: Previewing as Consumer — everything beyond the public tier is dimmed](/img/13.Digital-Data-Management/field-access-persona.png)

## Rationale, alignments and review

Every tier is a judgment call, and Field Access treats it as one instead of hiding it in configuration. Open any term's panel and it explains itself: the **rationale** for the default tier, the mandating source when there is one, and the term's **SKOS alignments** — pointers to matching concepts in external vocabularies such as schema.org, marked *exact* or *close*, which let you judge whether the annotation sits on the right concept in the first place.

![A term's detail panel | Figure 3: The manufacturing-plant term — mandated tier, rationale and SKOS alignment](/img/13.Digital-Data-Management/field-access-term.png)

Because judgment calls deserve second opinions, the panel carries a **reviewer workflow**: agree with a tier, propose a different one, flag an alignment as wrong, or mark it uncertain — with comments, and a resolve/reopen lifecycle so open questions do not evaporate. The **reviewer assistant** chat answers questions about a tier assignment, the ESPR rules behind it, or the alignment quality, grounded in the loaded schema — useful when the reviewer is a domain expert rather than an ontologist.

Reviewing is open to every signed-in user, deliberately: the people who know whether a field is sensitive are rarely the ones holding the admin role. Changing policies requires `dpp-admin`.