Business system integration: where to start

Describe one transfer of information

Start with a specific task. For example, a new shop order should create a job in the application used to manage the work, and the job reference should be returned to the shop. Define when an order becomes ready to transfer and what should happen if it changes afterwards.

That description separates an initial useful connection from later additions. Synchronising customers, prices, stock levels and sales documents introduces different rules for each type of record. These features do not all have to launch together, even when they involve the same two products.

Also record how employees handle the task today. A baseline helps establish whether the integration removes repeated data entry or simply replaces it with a different workload checking errors.

Decide which record takes precedence

The same customer may appear under slightly different names in separate systems. Prices might be maintained in one application and product descriptions in another. Assign responsibility for important fields individually instead of declaring one product authoritative for every kind of information.

The following fictional example connects a shop with an application used to manage fulfilment. It does not describe an existing client project or compatibility with a particular product.

Scroll the table sideways to compare data sources and update rules.

For each field, agree the format, unit and way of identifying its record. A product code is usually a better reference than a similar-looking name, but its uniqueness in both systems still needs checking. Ambiguous matches should be flagged for a decision rather than combined on an assumption.

Check the capabilities of your actual software version

An API is a supported way to exchange information with an application. A product having an API does not establish whether it allows the particular records to be read or written. Access may depend on a subscription plan, version, permission or additional arrangement with the supplier.

Before fixing the scope and price, check:

• whether the exact records and fields can be read and written;
• operation limits and any additional charges;
• notifications of changes, or the option to fetch updates periodically;
• a test environment that does not create real orders or dispatches;
• documentation and the supplier’s interface update policy;
• export options if the connection becomes unavailable.

A file import may be an alternative when a suitable interface is missing. Describe the delay and manual work honestly: who prepares the file, who checks it and how rejected rows are identified. A daily manual import should not be presented as continuously updated information.

Plan for delays, repeated operations and conflicting changes

The system sending a request might receive no reply even though the destination has saved the record. Retrying should not create a second job. Agree how repeated attempts at the same operation will be recognised and how its outcome can be checked later.

Supplier documentation contains concrete examples of these issues. Stripe describes duplicate delivery of events and does not guarantee their delivery order. Those are the rules of one service; the behaviour of the products used by your business must be checked separately. Stripe webhook documentation.

Decide how long a delay can be tolerated. Updates every few minutes may be sufficient for some reports and unsuitable for information required before someone can start the next task. Frequency should follow the business need and the capabilities of the connected systems.

A conflict also needs a rule. If two people change the same address in separate applications, the integration must know which record to accept or who should review the difference. Automatically keeping the most recent edit does not necessarily preserve the right business decision.

Make failures actionable

Office staff need to know which order is affected, whether it reached the other system and what to do next. A technical error written into a log does not provide enough information to answer a customer.

Include a view of pending records, the last successful exchange and a way for an authorised person to retry an operation. Distinguish incomplete information that an employee can correct from a connection failure that needs technical support. Also assign responsibility for reviewing the backlog after service resumes.

Keep access proportionate to the task. A connection that only reads product data has different requirements from one that changes customer records. Agree who manages the connection’s credentials and how access is removed or replaced when responsibility changes. The precise controls need to match the systems involved.

Test more than a successful transfer

Prepare acceptance checks for a normal order and less convenient cases: a missing product, an amended order, a repeated operation, a connection outage and incomplete customer details. Compare the records in both systems after each check rather than relying only on a “sent” message.

You should be able to distinguish records that arrived, records still waiting and records requiring a correction. For amounts and quantities, agree how totals and units will be reconciled. A useful integration leaves the result of its work visible and checkable.

Understand what determines scope and cost

The work depends on the types of records, directions of exchange, quality of identifiers, available documentation and exception handling. Separate the initial launch from the import of historical information and ongoing maintenance of the connection.

For an initial discussion, prepare the product names and versions, a sample record and a description of the task currently carried out by an employee. These materials make it possible to assess an integration as part of the business applications and connections offered by brigdev, then choose a limited but complete first scope.