Brand Setup & Readiness

Before a Digital Product Passport can be served to consumers, several brand-level prerequisites must be in place. This page explains what needs to be configured and why each element matters for a successful passport launch.

Brand Experience Requirements

The passport page is rendered with the brand’s visual identity. To ensure a professional, brand-consistent consumer experience, the following must be configured:

A brand logo is required for the passport header. The logo appears at the top of every passport page and establishes immediate brand recognition for the consumer.

  • Upload a logo via the brand settings in the tieback dashboard
  • Supported formats include PNG and SVG
  • A square icon variant is recommended for compact display contexts

Brand Colours

Primary and secondary brand colours are used throughout the passport layout — in headers, accents, and visual elements. Configuring these ensures the passport feels like a natural extension of the brand’s digital presence rather than a generic template.

Passports may reference the brand’s legal and support resources:

URLPurpose
Privacy policyLinked in the passport footer for regulatory transparency
Terms of serviceLinked where applicable for consumer reference
Support pageProvides consumers with a route to brand support

These URLs should be configured in the brand experience settings before publishing.

Domain and Resolver Requirements

Passports are served on the brand’s resolver domain. This means the consumer sees a URL that belongs to the brand — not a generic platform URL.

Platform Subdomain

Every brand on tieback receives a platform subdomain:

https://<brand>.tieback.io

This subdomain is available immediately after onboarding and supports all passport and resolver paths. No additional configuration is required to use it.

Custom Domain (Optional)

Brands can optionally configure a custom hostname — such as passport.yourbrand.com — to serve passports on their own domain. This requires DNS configuration and verification.

For setup instructions, see Custom Hostname Setup and DNS Setup Guide.

Product and Content Requirements

A product must meet certain conditions before its passport can go live:

Product Data Completeness

The product record should contain the attributes required by the applicable DPP schema. The specific fields depend on the product’s industry classification and the regulatory requirements that apply to it.

Published Passport Version

At least one passport version must be published for the product. Drafts are not visible to consumers — only published versions are served at the public runtime.

Active Assignment

A published passport version must be assigned to the product (or its batch). Without an active assignment, the resolver has no passport to serve, and the consumer will see an unavailable state.

For details on how assignments work, see Publication Lifecycle.

Launch Readiness

tieback provides an informational readiness summary that helps brand teams confirm whether the key prerequisites are in place before going live. This summary covers:

  • brand experience configuration (logo, colours, URLs)
  • domain and resolver setup
  • published passport availability
  • assignment status

The readiness summary is informational — it highlights what is complete and what may still need attention. It does not block publication. Brands retain full control over when to publish and assign passport versions.

Before serving passports to consumers, confirm the following:

  1. ✅ Brand logo uploaded
  2. ✅ Primary and secondary colours configured
  3. ✅ Privacy policy and support URLs set
  4. ✅ Platform subdomain active (automatic) or custom domain verified
  5. ✅ Product data populated for the relevant DPP schema fields
  6. ✅ At least one passport version published
  7. ✅ Published version assigned to the target product(s) or batch(es)
  8. ✅ Passport page reviewed on a mobile device to confirm the consumer experience

Step 8 — reviewing the passport on a real mobile device — is a recommended manual validation step. Automated checks cover configuration completeness, but the final consumer experience should be verified by a human before launch.