Retail integrations: what it takes to make connected systems work

Retailers often have good reasons to choose specialist software: an ERP for design, production, B2B, purchasing and finance, a warehouse solution, an ecommerce platform, a customer engagement application, even external PIM or OMS systems.

Avelon Next can serve as a unified operational retail core or participate in a broader ecosystem of specialist applications. Both approaches can work. The important decision is where responsibilities sit, and how the business will manage the handovers between them.

Many of these products offer APIs and standard connectors. Those are valuable. They can provide a tested way to exchange information and reduce the amount of custom development.

But an available connection does not establish how your company should use it.

Consider a product moving from a purchasing application to a PIM and then to Avelon Next and the webshop. Before that flow can operate reliably, the parties need to agree:

• Which application creates the product and assigns its identity?
• Who owns its variants, sizes, colours, barcodes and prices?
• Which system may update each field?
• What information must exist before purchasing, receiving or selling is allowed?
• What happens when two applications supply different values?

Two retailers using the same software can need completely different answers. One creates products during buying appointments; another imports them from supplier confirmations. One receives stock centrally; another also accepts deliveries directly in stores, etc., etc.

Software standards reduce technical differences. They do not remove differences in business processes. The practical question is therefore: how much of this connector matches our process, and what remains to be agreed, configured, built and operated?

Direct connections or an integration layer?

A point-to-point connection links two applications directly. An integration layer provides an intermediary through which applications exchange information. That intermediary may use an integration platform as a service, commonly called iPaaS.

Neither approach is automatically right for every retailer.

An integration layer can reduce duplication and improve visibility when it is designed and operated well. It also becomes an important dependency: its availability and recovery arrangements need attention too.

Most importantly, it cannot decide business rules by itself. For example, it does not inherently know whether a cancelled order should release stock, whether a parcel can still be redirected, or who may approve a delivery difference.

An integration platform provides tools. An integration owner makes sure the complete process works.

Moving a responsibility changes the integration

The size of an integration project depends heavily on where business responsibilities are placed. Product enrichment, product creation and warehouse operations create very different handovers.

When an external PIM enriches products

Suppose Avelon Next creates the operational product and an external PIM adds descriptions, images, composition and translations.

The main agreements concern product identity, field ownership, completeness and publication. For example, the PIM might own the commercial description while Avelon owns the selling price. Both systems need to respect that boundary.

Now suppose the roles are reversed: an ERP creates the product and Avelon Next enriches it. A different set of questions arises. Which fields remain managed by the ERP, and which can be maintained in Avelon? Does the enriched information flow back to the ERP, directly to the webshop, or both? What happens when the ERP updates a product that has already been enriched in Avelon? Those updates must respect the agreed field ownership, so they do not overwrite content maintained elsewhere. Changing where a responsibility sits changes what the integration needs to do.

This can still involve substantial work, particularly with variants, multiple channels and complex approval rules. However, a delayed description usually has a different operational impact from a delayed stock reservation.

When another application creates products

Now suppose a buying app, ERP or PIM creates the product first.

The integration must also establish when that product is usable in Avelon. A photograph and a supplier reference may be enough to record a buying intention, but not enough to receive goods or sell them at the till.

The parties must agree how incomplete products are handled, how variants receive their identities, how barcodes are matched and how duplicate creation is prevented. They must also decide what happens when a product arrives through more than one route, such as a buying app and a supplier EDI message.

When purchasing and warehouse logistics move outside Avelon

This changes the scope much more substantially.

If an external ERP or warehouse system manages purchasing and central stock while Avelon manages store operations, the shared processes may include receipts, allocations, reservations, picking, transfers, dispatch, returns and corrections.

Imagine that the warehouse dispatches five items to a store. The store receives four.

Where is the fifth item recorded? Who investigates the difference? Can the four received items be sold immediately? Which system updates availability for the webshop? What happens if the missing item arrives tomorrow?

The applications must coordinate the lifecycle of a business transaction. Exchanging a periodic stock total cannot, by itself, answer those questions.

“Stock” and “status” need precise definitions

Even familiar words can mean different things across applications.

Stock might mean physically present, available to sell, reserved, in transit, damaged or awaiting inspection. A webshop generally needs availability that reflects selling rules, rather than a raw count of everything physically present.

Similarly, “received” might mean that a parcel has arrived, that its contents have been scanned, or that the contents have passed inspection and are available for sale.

A customer order, a transfer, a parcel and a reservation are also different objects. They do not necessarily share one status. A customer order can be cancelled while a parcel is already on its way to the collection store.

The aim is an agreed, consistent account of what is happening. This does not require every application to show an identical number or status at every instant. It does require clear meanings, acceptable update delays and a way to identify and resolve differences.

Agree the integration contract before building

An integration contract describes what the parties exchange, what it means and how each side must respond. It includes functional and technical agreements, rather than just the commercial terms between suppliers.

A message can be technically valid and still request an inappropriate business action. A successful connection therefore needs business validation as well as secure data transport.

These agreements should also define access: which application may read or change which information, and who may authorise a corrective action.

Building is only part of the work

Once responsibilities are clear, the project still includes data mapping, development, configuration and testing across the participating applications.

The first successful order is an important milestone. It is not a complete acceptance test.

Joint testing should also cover partial deliveries, incorrect scans, cancellations, refunds, disconnected stores and peak trading volumes. What happens when two channels try to reserve the last item? What if one system completes an action but the confirmation never reaches the other? Can processing restart without duplicating a stock movement or refund?

Some failures can be recovered automatically. Others require a new business action. Goods that have physically left a warehouse cannot be brought back merely by resetting a software status.

Go-live also needs planning. Existing products, open orders, reservations and goods already in transit must be brought into the new arrangement without losing their meaning or being processed twice.

Everyday exceptions need visible answers

Good design reduces incidents and limits their impact. It does not eliminate changing circumstances, human mistakes or interruptions in connected services.

The following situations illustrate why operational visibility matters.

“Why is this product missing from the webshop?”

The product may be incomplete, awaiting approval, excluded from the channel, rejected by the destination, or successfully imported but not yet published.

Someone needs to follow its journey and distinguish these cases. A dashboard saying that all connections are available does not prove that the product reached its intended destination.

“The transfer was cancelled. Why does the other system report a receipt?”

Perhaps the goods were already dispatched when cancellation was requested. Perhaps cancellation was never accepted. Perhaps the receipt message was delayed.

The history must show what was requested, what was accepted and what physically happened. Automatically overwriting one status with the other could conceal the real issue.

“The shop has received a parcel, but the customer order is cancelled.”

The parcel's arrival remains a physical fact. The store needs instructions: hold it, return it, or release its contents to available stock after the appropriate checks.

Rejecting the receipt message without providing an operational resolution leaves the parcel and its stock position unresolved.

“Everything is green, but an order has stopped progressing.”

There may be no failed message. A message that should have been sent may never have been created, or an expected next step may never have occurred.

Monitoring must therefore identify overdue business steps and reconcile results, as well as report technical errors.

Monitoring needs people who can act

Useful monitoring answers four questions: what happened, what should happen next, what is affected, and who must act?

That requires traceable references across applications, understandable messages, alerts for failures and delays, and safe recovery procedures. Periodic comparisons of orders, stock and financial totals help detect differences that individual message checks can miss.

Responsibility should be agreed at three levels:

• The retailer's business owner decides process rules and resolves business exceptions.
• The integration operator monitors the flows, investigates handovers, coordinates incidents and carries out authorised recovery actions.
• The application suppliers investigate and resolve issues within their applications and agreed interfaces.

An external partner can provide integration operations. A retailer can also build that capability internally. Either way, technical outsourcing does not remove the need for a business owner who can make operational decisions.

For critical processes, agree monitoring coverage, response times, escalation routes and recovery expectations. Continuous monitoring and round-the-clock staffed support are different services; the required combination depends on the trading operation.

When a paid order stops on a Saturday morning, the retailer should already know who will take ownership of the incident and how the relevant parties will work together.

Integrations have a lifecycle and an operating cost

Applications evolve. APIs change, new channels are added, suppliers adopt different formats and the retailer changes its processes.

The budget should therefore cover more than the initial connection. It should distinguish design, implementation, joint testing and go-live from recurring platform charges, monitoring, support and maintenance.

It should also account for the retailer's own involvement and the cost of coordinating changes between suppliers. Documentation, access and ownership of integration components matter when a support provider changes.

When comparing proposals, ask what the quoted scope actually delivers: an available interface, a configured connection, an accepted business process, or an ongoing operational service. These are different commitments.

Choosing the right balance with Avelon Next

Avelon Next can bring connected retail activities together within a unified operational core, with integrations to specialist systems where they add value. It can also operate within a broader architecture in which responsibilities are shared with external applications.

Keeping related activities within the retail core reduces the number of external operational handovers to define, test and supervise. It still requires implementation, monitoring and support. Distributing those activities can offer specialist capabilities and greater freedom of choice, together with a wider integration responsibility.

An external PIM, for example, does not automatically require purchasing and warehouse operations to move to another ERP. Each boundary can be assessed on its own merits.

The same applies to the decision to introduce an ERP in the first place. A new finance or IT leader may bring valuable experience with systems used in a previous organisation. That can prompt a useful review, but the conclusion that “we need an ERP” should follow an assessment of the retailer's needs. Familiarity with a particular application or software category is not, by itself, a business requirement.

Start by identifying the capabilities that are actually missing. Which requirements can Avelon Next already meet? Which need a specialist application, and which could be addressed by improving configuration or processes? A retailer whose operational needs are covered by Avelon Next may be well served by a unified retail core connected to finance and selected specialist services. Another may have design, production or B2B requirements that justify a broader ERP. The case for adding a system should explain the additional value it brings, alongside the integration and operating responsibilities it introduces.

The right architecture depends on the capabilities the business needs, the value of the specialist applications and the organisation prepared to operate the whole arrangement.

Before choosing where to draw those boundaries, ask one question for each important process:

Who is responsible for making sure this business action is completed correctly, from beginning to end?

That answer is an essential part of a reliable integration.