Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Product data and language versions move between Odoo and Perfion on one agreed definition of what a single product actually is, so the same item does not end up listed twice in the catalogue.
Ask two people in the same business what counts as one product and you will get two answers. Odoo has a view, usually driven by what gets sold and stocked. Perfion has whatever view the implementation was given, which might treat every colour as its own thing or might not. Neither is wrong, and if they disagree the shop ends up listing the same jacket four times, or once with three colours missing. The Odoo to Perfion integration settles that question first, because everything else in the connection depends on the answer. That conversation is worth having before the first import.
DATA THAT FLOWS BETWEEN THEM
Products
Variants
Product attributes
Language versions
Categories
Prices
What counts as one product, and what counts as a variant of it, is agreed once and applied to everything, so the catalogue does not list the same item under several entries.
Translations live against the product rather than as separate products, so adding a market means filling in content instead of copying the catalogue and maintaining two of it.
Prices and codes come from Odoo and are not editable downstream, so the figure a customer is quoted is the same figure the business will end up invoicing them for.
New items arrive ready for content with their codes and attributes in place, so the product team writes rather than transcribing what somebody already entered in Odoo.
An item created in Odoo appears in Perfion as one product with its variants attached, so the product team adds descriptions and images to something that is already shaped the way the catalogue expects it to be.
A new market opens and translations are entered against the existing products in Perfion, so nothing is duplicated and the commercial data carries on coming from a single place in Odoo rather than being copied twice.
A new size or colour created in Odoo arrives as a variant of the product it belongs to rather than as a separate entry, so the shop offers a choice of sizes instead of showing what looks like two separate products.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
It depends what is slowing you down. If entering the same description in four languages is the bottleneck, a translation service is the obvious addition and it works from the product structure already agreed here. If the problem is getting content out to channels, that is a different connection. Both reuse this mapping rather than needing their own.
Yes, once the two systems agree what a variant is. That mapping is the substance of the work: which Odoo attribute makes something a variant rather than a separate product, and how that lands in Perfion. Alumio connects to Perfion over the interface it exposes, as it would any reachable system, and applies that mapping to everything afterwards.
No for the mapping, which is where nearly all of the work is. Fields, variants and language versions are matched in a form and maintained there by whoever owns the catalogue. Code becomes relevant only for a derived value neither system holds, such as a description assembled from several attributes, and the Code Transformer handles that at the step where it is needed.
Whichever one the shop sells from, in practice, because that is the shape a customer sees. Odoo often thinks in stockable items and Perfion in the thing being described, and those two are not always the same object. Settling it before the first import is what stops a jacket appearing four times, and it is a conversation between merchandising and operations rather than a technical decision.
A variant arriving as its own product is the failure to watch, because it publishes cleanly and the shop looks duplicated. Every transfer is monitored live. What it carried is logged. A refusal raises an alert immediately with the product and the reason. Retries run where configured, and anything unresolved stays on a list rather than quietly disappearing.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
