Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
What a Dolibarr install actually contains is decided by the modules somebody switched on, so WordPress orders are routed only to the ones this business runs rather than to a standard set.
Two businesses running Dolibarr can have almost nothing in common, because the system is assembled from modules and each one chooses its own. One has invoicing and stock, another has projects and little else, and a third turned on the customer module last year and has never used it. So a WordPress site feeding orders into Dolibarr cannot assume where anything belongs, and the usual result is a plugin that writes to whatever the developer had switched on at the time. Connecting WordPress and Dolibarr starts from what this install actually has, so an order creates the records the business actually keeps.
DATA THAT FLOWS BETWEEN THEM
Products
Prices
Stock
Third parties
Orders
Invoices
WordPress orders reach the Dolibarr modules this business actually switched on, so nothing is written to a part of the system nobody here has ever opened or maintained.
A WordPress buyer becomes a Dolibarr third party first and the order second, so the document points at somebody rather than merely carrying a name in a text line somewhere.
When the business enables another Dolibarr module, the WordPress flow is extended to reach it, so growing into the system does not mean commissioning the integration again.
The mapping between WordPress and Dolibarr lives in Alumio rather than in code somebody wrote once, so it survives the person who originally set the website up leaving.
An order is paid on WordPress and Alumio creates the Dolibarr records the business keeps, the third party and the document type it actually uses, so the order is filed the way this company files things rather than a default way.
Product prices and stock held in Dolibarr publish to the matching WordPress pages on the cycle you choose, so the shop quotes what the business will invoice instead of a figure typed in when the page was first built.
When somebody who has bought before orders again on WordPress, Alumio finds the existing Dolibarr third party and uses it, so the history stays on one record rather than growing a second one for the same person and address.
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.
Start with wherever the year end is actually prepared, because for most businesses running Dolibarr that is not Dolibarr. The bookkeeping package an accountant works in holds the version of the accounts that gets filed, and today somebody exports and reformats to get there. Alumio holds that connection alongside this one, so what WordPress sold reaches both without being typed a third time.
Yes, and the order in which things are created matters more than the schedule. Alumio resolves or creates the Dolibarr third party first, then the order or invoice against it, so a document is never left pointing at a customer that does not exist. Products and stock travel the other way on the cycle you set, because a price on a WordPress page can wait an hour and an order cannot. Creating the third party and the document stays within what Dolibarr accepts.
No, this is configured rather than coded. The thing it replaces is a form plugin somebody wired up once, which works until the business enables a Dolibarr module the plugin knows nothing about and nobody can say why the new orders look different. Which WordPress fields feed which Dolibarr records is held in Alumio. Where an install has been extended in its own way, the Code Transformer covers that step.
You do, and it is worth doing before anything is built rather than discovering it afterwards. Dolibarr only holds what has been switched on, so an order can arrive needing a document type this install does not have, and the integration then has nowhere honest to put it. Listing which modules are live, and which of them a WordPress order should touch, takes an afternoon and settles every question that follows.
A second copy of the same order, created when somebody tried again, is the failure worth designing against here, because both records look entirely valid. Alumio watches each write live and records the WordPress order reference against what it created in Dolibarr, so a repeated attempt is recognised rather than duplicated, and anything refused raises an alert with the reason. Retries run where configured, so nothing is quietly lost.
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)
