01
Product data is scattered
Parameters, descriptions, categories and relations sit in the ERP, the store, files and in the knowledge of specific people.
Pimcore for e‑commerce — central management of product data
We design and implement Pimcore as the central layer for product data, digital assets and publishing processes. It is the right direction for manufacturers and brands running a large catalogue, several sales channels or many language versions.
- For manufacturers
- Large catalogues
- B2B and B2C
- Many channels
One product, several inconsistent versions of the data
Product information rarely originates in one place. Some data comes from the ERP, marketing writes the copy, the technical department supplies documentation, and the store and the marketplace each have their own requirements.
With a small catalogue this model can be handled by hand. Over time new file versions appear, translations drift apart, parameters get different names and images end up without a clear owner.
The problem becomes visible during a product launch, a specification change or entry into another market. That is when the team works out which version is current, and then fixes it separately in several places.
02
Assets are not linked to the product
Images, videos, manuals and certificates have their own folders, names and versions.
03
Every channel needs separate work
The B2C store, the B2B panel, the marketplace and the catalogue may each need a different set of information.
04
Nobody knows who approves publishing
A product goes on sale with a missing translation, an outdated document or an incomplete specification.
The need for Pimcore follows from data complexity, not catalogue size
A few thousand simple products can be easier to manage than a few hundred items with many variants, documents, dependencies and market versions.
Pimcore can be justified when:
- one product has many variants, accessories, replacements or related documents,
- data originates in several departments or systems,
- the same catalogue goes to a B2C store, a B2B panel, marketplaces and partners,
- different markets need different descriptions, units, documents or images,
- publishing requires a completeness check and approval from several people,
- launching a new collection or updating the catalogue involves several teams,
- manually correcting the same information has become a regular part of the work.
Pimcore can be too early a step when:
- the company runs one small store and plans no further channels,
- the catalogue has a simple structure and is managed by one person,
- most of the data can safely be kept in the current sales platform,
- the problem comes mainly from the lack of an agreed process, not from system limits,
- the organisation has no data owners yet, nor a team that will keep data quality up.
How does Pimcore PIM support e‑commerce?
In ten areas, from where the information about a product is created to its publication in a specific channel. The scope of the system should follow from the data and from how teams work — not every organisation needs every area in the first stage.
Centralising product data
Classes, variants, parameters, units, relations and inheritance mirror the structure of the catalogue in one place. The model has to be understandable to the people who manage the offer and workable for the integrations.
What it means for e‑commerceA new category, product family or bundle no longer needs another makeshift structure in a spreadsheet.
Enriching product information
Base data can be extended with descriptions, benefits, applications, filtering parameters and whatever else the buying process needs.
What it means for e‑commerceThe team prepares the information once, and rules decide where and in which version it gets published.
Completeness checks
For every channel and market you can define which fields, translations and files are required before a product may be published.
What it means for e‑commerceGaps are visible on the product list before launch, not after a customer reports one or a marketplace rejects the listing.
Data quality validation
Rules watch the format, the range of values, the units and agreement with the dictionary. A value outside the dictionary is an error to fix, not a new value in the catalogue.
What it means for e‑commerceFilters and comparisons in the store work, because the same parameter is not recorded in five different ways.
Language versions
The same product can have different names, descriptions, documentation and depth of information depending on the market, while some fields stay shared across all of them.
What it means for e‑commerceAdding another language is not a matter of copying the whole product page and then policing changes by hand.
Images and documents
Images, manuals, certificates, videos and technical files can be assigned to products, variants, versions and channels. Pimcore ties asset management to product data and multichannel distribution.
What it means for e‑commerceChanging a document or an image no longer means hunting for every place the file was copied to.
Workflow
A product can move through preparation, translation, technical review and approval. Pimcore supports configurable workflows and states for objects, documents and assets.
What it means for e‑commerceThe team sees which products are ready to publish, what is missing and who should act next.
Automation
Repeatable work can be done by rules: assigning a category from an attribute, calculating a field, converting a unit, flagging a product as incomplete or triggering an export once the data changes.
What it means for e‑commerceThe team's work moves from copying data across to decisions about the offer and the content.
Distribution to many channels
Rules decide what data goes to the store, a marketplace, the B2B portal, an app, a catalogue or a trade partner.
What it means for e‑commerceEvery channel gets the scope of information it needs without keeping a separate master catalogue.
Several teams working together
Permissions and roles split access to classes, fields, languages and branches of the catalogue, so marketing, the product department, translators and the technical team work on the same record without overwriting each other.
What it means for e‑commerceThe next version of a file circulating by email stops being how product content gets agreed.
ERP, PIM and the e‑commerce platform — what does each system answer for?
The biggest risk appears when several systems store and modify the same information. Before the project starts, it has to be agreed where each piece of data originates, where it is developed and which channels may read it.
In a typical architecture the ERP stays the source of operational data such as item codes, base prices, stock or logistics information. The exact scope depends on the company's current environment.
Pimcore holds the rich product structure. This is where sales descriptions, relations, translations, documentation, asset assignments and readiness statuses can be created.
Magento 2, Shopify or another platform is responsible for presenting the offer, the customer account, the cart and the transaction. It receives data prepared for that specific channel.
Example directions of data exchange
ERPPimcore
Item codes, base data, reference prices, logistics information
PimcoreMagento 2 and Shopify
Product structure, descriptions, attributes, relations, assets, language versions
PimcoreMarketplaces and partners
Field sets mapped to the requirements of a specific channel
WMSSales platform
Stock levels, locations, shipping data
Sales platformERP
Orders and the data needed to fulfil them
What each system answers for
ERP
operational and transactional processes
- stock levels
- prices
- documents
- warehouse and business processes
Pimcore PIM
the information about the product
- descriptions
- attributes
- product relations
- media
- documents
- language versions
- data completeness and quality
- preparing information for individual channels
Magento 2 / Shopify
the sale and the buying experience
- presenting the offer
- the buying experience
- the cart
- checkout
- the sales process
The exact split of data depends on the architecture of the specific project. In one implementation reference prices go into Pimcore, in another they flow from the ERP straight to the store; the same holds for stock, logistics data and information about business partners.
Pimcore in omnichannel selling — one product, many channels
The data is managed centrally and only then prepared for what a specific channel expects. The same product reaches the store, a marketplace and a catalogue in three different sets of fields, but from one source.
Every recipient has different length limits, different required attributes, a different category structure and different expectations of images. In Pimcore those differences are channel data rather than separate files kept alongside the catalogue.
Where the data goes
- Magento 2
- The full range of descriptions, attributes, relations and media, together with store views for individual markets.
- Shopify
- A range matched to the platform's data model: a narrower set of fields, its own handling of variants and markets.
- Marketplaces
- Shortened names, the channel's required attributes and categories — and, coming back, the publication status and the reason a listing was rejected.
- Apps
- Sales, service and warehouse apps pulling only the fields they actually use through an API.
- Catalogues
- Data and media for catalogues, product sheets and printed materials, in a version prepared for print.
- Product pages
- Landing pages and product microsites drawing on the same descriptions as the store.
- Trade partners
- Distributors and retail networks receive an agreed scope of data and files, without access to the whole catalogue.
- Further countries and languages
- A new market adds translations and local data to the existing model instead of copying the catalogue.
Adding a channel is then work on mapping and publication rules rather than on another copy of the catalogue. How the connections are built is described by Pimcore integration.
Pimcore for large and complex product catalogues
Scale is decided less by the number of items than by how many dimensions the catalogue has: variants, relations, bundles, technical attributes, markets and languages. Pimcore copes with them because the data model is designed around the specific assortment.
Not every catalogue grows in the same direction. One has half a million variants of identical structure; another has two thousand products with spare parts, technical documentation and separate standards per market. The first is a job for performance and imports, the second for modelling — and that distinction drives the architecture of the implementation.
What the data model handles
- Products and variants
- The base product and the axes that split the offer, with field inheritance, so changing a description does not mean editing every variant separately.
- Relations between products
- Accessories, replacements, complementary products and parts — as links in the model, not as a list of codes typed into a description.
- Bundles
- Products made of other products, together with the rule for what they inherit from their components and how they are presented in a channel.
- Elaborate attribute structures
- Attribute groups per product family, field types, value dictionaries and units of measure — instead of one flat list of columns.
- Many categories
- Parallel trees: the store's own structure beside the one a marketplace requires and the one used in the printed catalogue.
- Technical data
- Parameters, value tables and standards, from which channels build filters, comparisons and specification sheets.
- Media
- Images, renders and videos linked to the product, the variant and the market, with roles and display order.
- Documents
- Manuals, certificates, datasheets and declarations, in versions that depend on the market and its legal requirements.
- Translations
- The split between translated and shared fields, with the state of each market's translation visible.
- Local data per market
- Names, units, depth of information and formal requirements that differ in every country, inside one product record.
Scalability comes from the data model and the architecture, not from a claim about any number of products. At high volumes we also check import performance, how long a change takes to propagate and how the team works in the panel — because those, rather than the row count in the database, are the limit a project actually trips over.
Pimcore as a PIM or as a Digital Commerce platform?
Pimcore can work as a PIM data layer for external sales platforms such as Magento 2 and Shopify, but it also has its own E‑Commerce Framework for building individual commerce solutions.
A PIM data layer
the common case
Pimcore holds the product information and the assets, while selling stays in Magento 2, Shopify or another platform. The store receives data prepared for its own requirements and still answers for the cart, the checkout and customer accounts.
- an off-the-shelf sales platform
- a shorter route to launch
- the store maintained by the platform vendor
- Pimcore answers for the data, not the transaction
The E‑Commerce Framework
the individual case
The framework covers components for, among other things, product structure, pricing, availability and commerce processes. Pimcore's current documentation still develops it as a module of the platform — it is a toolkit for building your own commerce architecture, not a ready-made storefront.
- your own architecture for the sales process
- sensible with an unusual commercial model
- needs development and upkeep on the company's side
- not a 1:1 equivalent of a SaaS platform
Pimcore is not a ready-made online store comparable 1:1 with Shopify, and we do not present it as one. If the selling should stand on a proven platform, the right direction is Magento 2 or Shopify with Pimcore as the data layer.
How we prepare Pimcore to work with your e‑commerce
An implementation starts from the data, the systems and the way the team works today. On that basis we design the product model, configure the processes, prepare the migration and connect Pimcore to the channels that are to use the data.
- 01
Analysis of data and systems
We check where product data originates today, who updates it and which systems and channels it has to reach.
What the stage deliversThe ERP, files, the current store, data sources, sales channels and team ownership
- 02
Product model design
We agree the structure of classes, variants, attributes, relations, units, language versions and assets that Pimcore will handle.
What the stage deliversAn agreed data model matching the catalogue and the requirements of the sales channels
- 03
Preparing data for migration
We map data from the current sources onto the new model, name the gaps and agree the rules for importing into Pimcore.
What the stage deliversIt is clear which data will be moved, where it comes from and where it lands in the new structure
- 04
Pimcore configuration
We build the data model, fields, relations, user roles, statuses, workflows and the rules for working with products and assets.
What the stage deliversAn environment that matches the processes the team uses to prepare data for sale
- 05
Integrations with systems and channels
We connect Pimcore to the systems that supply or receive data, such as an ERP, WMS, Magento 2, Shopify, a marketplace or a B2B portal.
What the stage deliversEvery system receives an agreed scope of data from the right source
- 06
Testing and go-live
We check the imports, rules, workflows and data flows between Pimcore and the other systems before the production environment goes live.
What the stage deliversA verified Pimcore environment ready for the team and for the e‑commerce channels
The team works on one shared product status
Pimcore organises the system, but the result also depends on agreeing who is responsible for what. Every stage needs an owner and a clear definition of done.
The system will not replace data owners. It should give them the process, the statuses and the tools they need to keep quality up.
Who works in the system
E‑commerce Manager
Visibility of catalogue completeness, readiness to publish and the issues blocking a launch. Instead of collecting statuses from several departments, they work on one queue of products and changes.
Product team and marketing
One place to prepare descriptions, translations, images, documents and sales materials. Information can be developed without editing every platform separately.
IT and integrations
An agreed data model, named sources and named recipients. Changes to the product structure can be analysed before they reach the store, the ERP and the other channels.
FAQ — Pimcore for e‑commerce
The questions that come up most often before a decision: what a PIM gives online selling, how responsibility splits between systems, the scope of the first stage and how to prepare for the analysis.
Ask a question about your catalogueOne place where the information about a product is created and checked, and rules by which it reaches the channels. In practice that means a shorter route from a change in the data to publication, visible completeness before launch, and an end to reconciling the same descriptions by hand in the store, on a marketplace and in the catalogue.
A PIM becomes justified when data is scattered, the catalogue has a complex structure and the same products are published in many channels, languages or market versions. The number of SKUs alone is not enough to decide — a few thousand simple products can be easier to run than a few hundred with variants, documentation and separate requirements per market.
An ERP runs the operational and transactional processes: stock, prices, documents, the warehouse and settlements. A PIM runs the information about the product: descriptions, attributes, relations, media, translations and data completeness before publication. Pimcore usually does not replace an ERP, and the exact split is agreed against the current architecture.
No. Pimcore works alongside a sales platform as the source of product data and assets, and Magento 2 or Shopify still handle the shopping experience, the customer account, the cart and the transaction. Pimcore does have its own E‑Commerce Framework, but that is a toolkit for building an individual commerce architecture, not a ready-made store.
Yes. Pimcore passes the product structure, descriptions, attributes, relations, media and language versions, and Magento 2 stays responsible for the sale. The scope of the connection covers field mapping, the directions of synchronisation, error handling and update rules — it is described by Pimcore integration.
Yes, with the same split of responsibility. The difference is the platform's data model: Shopify accepts a narrower range of fields and handles variants and markets differently, so the channel data is prepared around what it can take. How the connection is built is described by Pimcore integration.
Yes, and it usually needs a set of data of its own: shortened names, the channel's required attributes and its categories. Coming back the other way, it is worth recording the publication status and the reason a listing was rejected, so the team can see which items did not reach the channel and why.
Yes. The model settles which fields are translated, which are shared across markets and which are local, plus a separate definition of completeness per market — a product ready to publish in Poland need not be ready in Germany. The state of the translations is visible in one place instead of in a spreadsheet per country.
Yes, that is the platform's DAM area. Images, renders, videos, manuals and certificates are linked to the product, the variant, the language version and the channel, so changing a file does not mean hunting for every place it was copied to.
Yes, and it often serves both channels at once. B2B selling usually needs technical data, documentation, bulk units and a wider range of attributes, while D2C needs sales content and media. That is the same product in Pimcore with two sets of channel data, not two catalogues.
Pimcore has its own E‑Commerce Framework, but it is meant for building individual, configurable commerce architectures rather than being a ready-made storefront that behaves like a typical SaaS platform. It can make sense with an unusual sales model; otherwise it is faster and cheaper to put the selling on Magento 2 or Shopify, with Pimcore as the data layer. The two variants are compared in the section on PIM and Digital Commerce.
Usually it does not. The ERP can still be responsible for operational data, prices, logistics, stock and financial processes. Pimcore develops the information needed to present the product and publishes it to the channels.
The scope should follow from the organisation's problems. The first stage can cover the product data model and selected assets. Further areas can be planned once the dependencies, users and priorities are clear.
Sample product data, a list of systems, a description of the current process, channel requirements, a set of the most frequent problems and the people responsible for the data all help. The materials do not have to be tidied up in advance.
If the platform runs but needs a takeover, stabilisation, updates or a growth backlog, the right path is Pimcore maintenance. A new integration or a rebuild of data exchange belongs to Pimcore integration.
Let's find out where data originates and how it reaches sales
Tell us about your current catalogue, systems and channels. The first thing to establish is whether the problem calls for Pimcore, a new integration, or simply order in the current environment.
[email protected]ul. Jana Henryka Dąbrowskiego 28, 15-872 Białystok, Poland
In the first call we go through
- the sources of product data
- your current sales channels
- the structure of the catalogue and the assets
- the most frequent errors or delays
- the markets and channels you are planning
- the people responsible for preparing information