what a library connection is.
Alumio has a large library of existing connections, which can serve as a template for a new integration. The library is mainly meant to give less experienced users a quick basis. It is boilerplate: a starting point, so you do not start from zero.
what a template does cover.
A template assumes the standard situation: two systems behaving as their makers intended, with data that means the same in both. Then a template covers a lot: the connection to both systems, familiar objects such as products, customers and orders, and fields that carry over one to one, such as an article number. If your process follows that standard course, a template is a large part of the work.
where it stops: your rules.
Most customers we work for have oddities in their process. Those rarely sit in the connection and almost always in the rules, usually here:
- Pricing. Customer-specific prices, volume tiers, discount agreements, or a price the ERP calculates differently from what the webshop expects.
- Stock. Several warehouses, reserved stock, or which stock the webshop may show.
- Statuses. Your own order statuses, when an order counts as "shipped" or "completed", and what happens with a partial delivery or return.
- Exceptions. One customer group, one country or one product group that is handled differently from the rest.
- Legacy quirks. Fields that have come to mean something other than their name says, codes that only mean something internally, and limits of an older API.
A template does not know those rules. They are not in the standard of either system, but in your setup and in the heads of the people who work with it every day. That is where the generic part ends.
That also holds for common combinations. We have connected an ERP to Shopify many times, and still the setup differs per company, because the exceptions differ.
what configuring means in practice.
Moving away from the generic components is not separate software development but setting up the platform for your process. In practice that comes down to:
- mapping fields differently from the template, or adding fields the template does not know;
- adding conditions: if customer group X, then this price; if warehouse Y, then this stock;
- an extra step for an exception, such as a return the ERP books differently;
- deciding what happens when a message cannot be processed, and who sees it.
The template remains the skeleton; your own rules go on top, in configuration you can read back later.
Say a wholesaler sells through one webshop to consumers and to business customers with their own price agreements in the ERP. A generic connection assumes one price per article: right for consumers, wrong for every business customer. That rule is standard in neither system, so a template does not know it. The solution is not another platform but a price flow that fetches the right price per customer group.
when a library connection helps.
- Your process follows the standard behaviour of the two systems and has few exceptions.
- You want to see a first version quickly, before you work out the rest.
- Your team has experience with Alumio and adapts the basis itself.
when to start custom straight away.
- Your process has exceptions you cannot or do not want to drop.
- One of the systems is a legacy system, or one we have not connected before.
- Dependability weighs heavily: lost orders or double bookings are not acceptable.
how to decide up front.
You do not answer the question "template or custom" in the library, but in your own process, in three steps.
- Write down per flow, in plain language, what happens, with the people who do the work every day, not only IT.
- Mark what deviates from the systems' standard behaviour. That is where the template stops and the configuration begins.
- Count the flows and name the systems: known or legacy.
The same three things set the price: the kind of systems, the number of flows and the overall complexity. We first check technically whether the integration is possible, then give a fixed price for the agreed scope. As long as that check happens first, you run little to no risk. More on that in what does an ERP integration cost?.
what to ask a supplier.
If you get a proposal based on a library connection, ask:
- Which part comes from the library, and which is set up for us?
- How do you handle this exception? Name one and ask for a concrete answer, not "that is possible".
- What happens when an order cannot be processed, and who sees it?
- Do you check technically whether it is possible before the price is fixed?
- What sets the price, and what falls outside the agreed scope?
Whoever answers these calmly has thought about your process; whoever only points at the library is selling you the starting point.
You can read more about how we judge this in has this been done before?. Want to know how much custom work your integration needs? Tell us how your processes run, and we will tell you in one call what it involves.
