CONCEPT Cited by 1 source

Presentation policy¶

Definition¶

A presentation policy in Zalando's Interface Framework is a named, valued directive inside an Experience that tells a domain backend how to shape its GraphQL response for a request. Policies are the what-to-apply half of the Experience mechanism; they pair with selection metadata (the when-to-apply half).

Canonical shape (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando):

"policies": [
  {
    "name": "THEME",
    "value": { "name": "THEME_NAME", "theme_config1": [] }
  },
  {
    "name": "PRODUCT__FLAGS__HIDE_SALE",
    "value": true
  }
]

Two fields:

name — a hierarchical policy identifier. The PRODUCT__FLAGS__HIDE_SALE form implies domain__group__property namespacing (domain: PRODUCT, group: FLAGS, property: HIDE_SALE).
value — a domain-typed value. Can be primitive (true) or a nested object ({name, theme_config1, …}).

Policy name conventions (inferred)¶

From the two examples:

THEME — unnamespaced root-level cosmetic policy; value is a theme config object.
PRODUCT__FLAGS__HIDE_SALE — double-underscore-namespaced boolean flag on a product domain.

The double-underscore separator suggests a path-like naming scheme to avoid collisions across domains. The post does not enumerate the full policy vocabulary.

Policy surfaces — broader than just theme¶

Two examples in the post:

Policy	Surface	Effect
`THEME`	Presentation	Swap packshot background from grey to white, apply brand-distinctive typography / colour
`PRODUCT__FLAGS__HIDE_SALE`	Catalog admission	Hide sale products entirely from the brand's elevated view

The HIDE_SALE example is architecturally significant: policies can filter results, not just restyle them. Zalando explicitly notes "some brands are only to be shown in the product catalog when the brand or its products are explicitly requested to be shown by specific search queries or via catalog filters" — that admission policy is enforced by the Experience's policy list.

This makes Policy closer to a server-side feature flag scoped to an Experience than to a pure theming directive. Compare with concepts/feature-flag: Experience policies are feature flags that vary per Experience per request, not per user per deployment.

Who reads policies¶

Policies are read by the domain backend serving a given Renderer's GraphQL query, not by the Renderer itself. Zalando's example: "In the catalog, we have product cards, whose data is populated by a different backend, the Product backend. As we have already resolved the experience, the Product backend can now understand which policies are required. For Zalando's experience it will select the gray background images with the watermark, instead of the white ones." (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).

The Renderer's React code is unchanged across Experiences — it still calls its withQueries GraphQL block, still renders what comes back. The data that comes back differs per Experience because the Product backend chose different image URLs based on the Experience's policies.

Policy ≠ config¶

Policies are per-Experience, resolved per-request. Configuration is per-deployment. The architectural difference:

Config — one value for the running process; changes via deploy or feature-flag service fan-out.
Policy — one value per (Experience × request); every request carries its Experience, so every request sees potentially different policy values.

Not disclosed¶

The full policy namespace (only THEME and PRODUCT__FLAGS__HIDE_SALE named).
How multiple policies on the same key are combined (if that case is even allowed).
Whether policies can be composed across Experiences (e.g. an Experience inheriting policies from a base).
Value-type schema / validation rules for policies.

Seen in¶

sources/2023-06-25-zalando-context-based-experience-in-zalando — canonical shape; the THEME and PRODUCT__FLAGS__HIDE_SALE examples; the framing of the Product backend as the reader of policies.