Pimcore Product Experience Portal – Make Your Product Data Self-Service.

A Product Experience Portal (PXP) is one of two portal variants enabled by Pimcore's enterprise-only Portal Engine bundle, marketed as "Experience Portals." Primary data here is Data Objects, i.e. products, along with their associated assets. The target audience is dealers, sales, and partners who need to browse, filter, and export product data without getting a Pimcore backend account.

What Exactly Is a Product Experience Portal?

A PXP builds on your existing Pimcore data model: product Data Objects with their attributes supply the facets for search, linked assets supply images and documents. The portal is built configuration-driven: data pools, permission sets under a workspace concept (organized by folder structure), navigation, filters, and theming exist as configuration documents in the backend, complemented by optional code customizations. That's what sets a PXP apart from classic custom development: most of the work is configuration, not building a frontend from scratch.

Portal Users Aren't Backend Users

One central, often-misunderstood detail: portal users are their own Data Objects of type PortalUser, authenticated against a dedicated portal firewall, not regular Pimcore backend users. "10,000 dealer logins" therefore don't touch backend user management at all: portal access stays fully separate from the Pimcore backend, a security and governance advantage, not a licensing question (Pimcore has no per-user licensing model to begin with). Single sign-on runs through an OpenID Connect integration, compatible with common identity providers like Entra ID, Keycloak, or Okta.

Technical Prerequisites That Often Get Overlooked

A PXP has hard infrastructure prerequisites that need to be settled before project start: the Generic Data Index with OpenSearch 2.7 or later, or Elasticsearch 8.0 or later, typically combined with Enterprise Asset Metadata and Statistics Explorer. Without a running search cluster, there's no functional portal. That's the most common reason portal projects stall right at the infrastructure phase when this wasn't planned for in advance.

Features That Matter Day to Day

Faceted search over indexed product attributes, download carts that bundle multiple products into a ZIP, public token links with an expiration date and optional terms-of-use acceptance, plus guest or open portals, these too remain permissioned via guest users and access rules (PQL preconditions), not open in the sense of unprotected.

Where Portal Engine Reaches Its Limits

Portal Engine is a configurable product, not a headless framework for pixel-perfect, fully custom design. Anyone who needs a bespoke frontend experience without the conventions of Portal Engine configuration is better served with a custom frontend on Datahub or the Generic Data Index. Equally important: portal permissions protect the portal interface, not automatically the raw asset URLs behind it. Without an additional webserver lock, direct asset links stay publicly reachable: a point we deliberately factor into every portal project instead of assuming it away.

The Workshop Before the Configuration

The most common cause of time and budget overruns in portal projects isn't the configuration itself, it's a skipped requirements workshop: which audiences exist, which data pools do they see, which permission matrix applies per group? We deliberately run this workshop before the first line of configuration, not in parallel with it, the same principle behind our Enterprise Data & MDM work. That costs a bit more time up front and saves exactly the rework that otherwise surfaces when an audience requirement turns up mid-configuration.