An order arrives in your online shop, but someone still has to enter it into another application, check the customer details and notify the person responsible for fulfilment. Each task may be simple. Repeated every day, they take time and make it harder to tell which information is current.
An integration can connect these steps, but moving data is only part of the job. You also need to decide what should happen, which system holds the authoritative information and how the business will notice a failure. Here is a practical way to approach that work without replacing every tool you use.
When connecting systems makes sense
Look for information your team regularly copies: customer details, order lines, job statuses or document numbers. It is also worth investigating cases where two departments hold different versions of a record or must ask each other for an update before proceeding.
Before commissioning an integration, check the capabilities of your existing tools. A supplier may already offer a connector, file import or setting you have not used. For an occasional task, a well-organised export and import may be enough. Custom development becomes worth considering when existing features cannot handle the required information, rules or exceptions.
You do not have to automate the entire workflow. If transferring orders is the problem, that can be the first stage. Automatic invoicing, stock updates and customer messages may each require separate decisions and tests. A narrow starting point makes those responsibilities easier to understand.
An example: from shop to order handling
Imagine a trading business that sells through an online shop and manages fulfilment in a separate application.
Once an order is placed, the shop makes its data available. The integration checks required fields, records the relationship between order numbers in both systems and creates a record in the fulfilment application. An employee is notified that the order is ready for review. If a delivery address is missing, the order is flagged for clarification rather than passed on with incomplete information.
The employee still decides whether to proceed with fulfilment. This first stage automates the transfer of information, not every business decision. It gives the company a way to assess the connection before granting it permission to carry out further actions.
What to agree before development
Describe one request from beginning to end. Who enters the information? Who corrects it? Which department needs it, and at what point? Sample orders without real customer details and a list of the applications involved are useful starting material.
Source of information. Decide which system owns each type of information. The shop might hold the customer's order while an internal application holds its fulfilment status. That does not mean both should freely overwrite every field. Agree what happens when someone makes a manual correction.
Direction and timing. Does information travel one way or both ways? Must it arrive immediately, or would periodic synchronisation be sufficient? Two-way connections need additional rules for conflicting changes. They should serve a specific need rather than be included by default.
Identifiers and field meanings. A product or customer can have different reference numbers in different tools. A company name alone is rarely a reliable match. Agree how identifiers relate, what statuses mean and which date formats and units apply before automating the exchange.
System access. An application programming interface, or API, lets applications exchange data. Supplier documentation describes the available actions, usage limits and authentication requirements. An API does not necessarily expose everything available in the user interface. Check costs and whether a test environment is available too.
Permissions. Give the integration the access needed for its agreed task. Establish who manages its account, where credentials are stored and how they can be changed or revoked. Customer details should not be copied into error logs without a justified need.
Plan for failures as well as successful transfers
The key question is whether the business will notice when some orders do not arrive. An absence of error messages does not prove that everything was processed correctly. You need a way to identify successful operations and those requiring attention, with enough context for someone to investigate.
Repeated orders or notifications
A system may send the same notification again. For example, Stripe's documentation describes duplicate event delivery and recommends identifying duplicates. Receiving the notification twice should not create a second order. The method for recognising repeats depends on the operation and the receiving application's capabilities.
Missing or invalid information
Sending an order again does not fill in a missing mandatory field. The record needs a clear reason for being held and an identified person to resolve it. After correction, there should be a safe way to resume processing without manually recreating the entire order.
An unavailable application
A temporary outage may justify another attempt. Delays, attempt limits and stopping conditions should reflect the supplier and the type of failure. Not every error is temporary: invalid permissions need a different response from a short connection interruption. Microsoft's retry guidance explains why this distinction matters.
Also consider an order that was saved successfully when the response never reached the sender. A retry must not create another copy. Handling repeated operations needs to be designed alongside retries, rather than added after the first incident.
Start with one flow and evaluate it
Choose one transfer and agree how you will assess improvement. Useful checks include manual steps, completeness of transferred fields, consistent statuses and the number of records needing clarification. Compare the same kinds of requests before and after the change, including time spent correcting problems.
Prepare examples covering an ordinary order and exceptions: a missing address, changed details, repeated delivery and an unavailable destination. Use a test environment first if one is available. You can then agree a limited launch, a way to stop the integration and a documented procedure for handling work manually.
Avoid promising a particular saving in advance. Results depend on existing work, data quality and the frequency of exceptions. The first stage should establish whether the connection helps and what needs changing before you extend it. It may also show that a simpler approach is sufficient.
Decide who looks after the integration
A supplier may change its API, access rules or a feature your connection relies on. Credentials can expire, fields can be added and your own order-handling process can change. Responsibility for monitoring, reporting faults and making adjustments should therefore be part of the delivery discussion.
Agree who receives notifications, who can resume a stopped operation and where the connection is documented. Cover support arrangements and running costs as well. Getting an integration working once does not replace an agreement about ongoing operation, even when it initially covers only one workflow.
How to start the conversation
You do not need a technical specification. Start with a few practical questions:
- Which information do people copy, and between which tools?
- How often does this happen, and who handles it?
- How do you notice an error or missing record?
- Which single step would you like to improve first?
These answers help establish what your current tools can do and where to start. Explore workflow automation and integrations or tell me what you would like to improve.