System Integration: Connect the Work, Not Just the Software

01

Connected software can still create disconnected work

Imagine an established maintenance business. New enquiries arrive through the website. Customer and sales information lives in a CRM. Engineers and visits are managed in a job system. Approved work is invoiced through finance software. Documents sit in another service.

Every product is useful. The problem appears between them.

An administrator copies the new enquiry into the CRM. A salesperson wins the job and emails operations. Operations creates another customer record and retypes the address. Finance receives a spreadsheet at the end of the week. When a customer asks for an update, the answer depends on which system somebody checks first.

System integration is often described as making applications exchange data. That is correct, but it is not enough. The business needs the applications to support one joined piece of work. The enquiry should become the right customer, the accepted quote should become one job, the completed visit should prepare an invoice and every handover should leave evidence that somebody can trust.

That is the standard worth using. A connection is valuable when it improves the operation, not merely when two technical teams can prove that a message crossed the gap.

02

What system integration means in business terms

System integration connects applications, data, services or devices so they can contribute to a coordinated process. The connection may transfer information, request an action or announce that something has happened.

An application programming interface, usually shortened to API, may let the job system request the current customer details from the CRM. A webhook may tell the finance system that a job has been approved for invoicing. A scheduled file may update thousands of product records overnight. A queue may hold work safely while a slower system catches up.

Those methods solve different problems. The design should begin with the business event and the required outcome, then choose the lightest technical route that can deliver it reliably.

For the maintenance business, the first event might be quote accepted. The intended result is one approved customer and one new job containing the correct site, contact, scope and commercial reference. That is much clearer than a broad instruction to integrate the CRM and job system.

03

Give every important fact an owner

Integration becomes messy when several systems are allowed to be equally correct.

The CRM may contain the sales contact, the job system may hold the service address and finance may maintain the legal billing details. That can be sensible, but the business must decide which application is authoritative for each fact and which changes are allowed to travel back.

Without that decision, a two-way synchronisation can create an expensive argument between databases. A corrected email address moves from the CRM to the job system, an older value returns during the next update and staff no longer know which record to trust.

A short data ownership table is more useful than a complicated architecture diagram at this stage. It should name the field, its authoritative system, who can change it, where copies are needed and how conflicts are handled.

The same discipline applies to identifiers. Names and addresses change. An internal customer ID, job ID or supplier reference gives the integration a stable way to recognise the same record across systems. Store the external identifiers needed for tracing and duplicate protection rather than repeatedly trying to match records from loose text.

04

Choose the lightest connection that fits the event

There is no single best integration method. Microsoft guidance separates real-time request and response, asynchronous messaging, webhooks and batch transfers because latency, volume and failure behaviour change the right design.

A pre-built connector is a sensible first choice when it supports the real workflow. It is usually quicker to configure and leaves less custom code to maintain. The word connector still needs testing. It may move contacts but not company relationships, synchronise once a day rather than immediately or omit the field that actually controls the handover.

A direct API call works when one system needs an immediate answer or action. The CRM can ask whether a customer account is active before accepting an order. The user may need to wait for the response, so timeouts and temporary failure affect the screen they are using.

A webhook or event works when one system needs to announce a change without making the original user wait for every later step. The job system can publish visit completed, allowing invoicing and reporting to continue separately. A queue can hold that work when a receiving service is unavailable.

A scheduled batch or file transfer can be entirely appropriate for large or slow-moving data sets. Overnight product costs do not need an elaborate live event stream when the business only changes them once a day. Batch work still needs validation, reconciliation and evidence of the last successful run.

An automation platform or integration service can coordinate several products without creating a new application. This is useful for stable, understandable handovers. Custom code earns its place when the mapping, volume, recovery rules, security needs or review experience are too specific for the available connector.

05

Reliability is part of the feature

The happy path is the easy part of an integration demonstration. A quote is accepted, the job appears and everyone smiles. Live systems are less polite.

The receiving API becomes unavailable. A webhook is delivered twice. A field changes format. A user merges two customer records. One action succeeds and the next one fails. An old access token expires. The original system retries after a timeout even though the first request actually completed.

Important integrations need duplicate protection. If the same quote accepted event arrives twice, it should update or confirm one job rather than create two. This property is often called idempotency. The ordinary business description is simpler: retrying the same handover must not repeat the commercial action.

Retries also need limits. A temporary outage may justify another attempt in a few minutes. Invalid customer data will not improve after the fiftieth retry. That case needs to appear in a review queue with the reason, the affected record and a safe way for a person to repair or replay it.

Logging should answer ordinary support questions. Which event arrived? Which record was involved? What decision did the integration make? Which system accepted the update? What failed next? Logs should avoid exposing secrets and unnecessary personal information, but they must contain enough context to investigate the handover.

Finally, reconcile the systems. A daily check might compare approved jobs with finance records and flag any that never reached invoicing. Monitoring that only proves the integration process is running can miss the business record it quietly lost.

06

Security crosses every system boundary

An integration creates another route into business data and actions. It therefore needs deliberate identity, permissions and data handling.

Use business-managed service identities rather than credentials belonging to one employee. Grant the smallest permissions the connection needs. A job integration that reads approved customer details and creates work orders should not automatically receive the power to export every contact or delete finance records.

Verify incoming webhook requests using the supplier's supported signing method. Store secrets outside the source code. Protect data in transit. Review access when a supplier, system or process changes. Record important actions in a form that can support investigation and audit.

Data protection should be considered while the integration is designed. The UK Information Commissioner's Office describes data protection by design as considering privacy and data protection issues in systems, services, products and processes from the start. That means knowing which personal data crosses the boundary, why it is needed, where it is retained and which organisations can access it.

Security is not solved by using an API. The API is the doorway. Authentication, authorisation, input validation, rate limits, logging and operational ownership decide whether that doorway is controlled.

07

The real advantages appear in the workflow

The common benefits of system integration are credible, but they should be measured in the work rather than repeated as broad promises.

Less manual entry is useful when it removes a real copy step and does not create a larger exception queue. Faster handovers matter when the next team can act sooner. Better information helps when staff can see the current record and its origin. Reduced duplication matters when the business has decided how duplicate records will be prevented and repaired.

For the maintenance company, useful measures could include enquiries entered once, accepted quotes that become jobs without re-keying, failed handovers waiting for review, time from job approval to invoice preparation and customer updates answered without searching several systems.

Cost saving may follow, but it should not be assumed before the workflow is understood. Integration introduces licence fees, implementation work, monitoring, support and future changes. It can still be a strong investment when it removes enough repeated work, improves control or protects an important customer journey.

The strongest benefit is often confidence. Staff can see where a record came from, who owns it and whether the handover completed. Managers can distinguish a late job from a missing update. Customers receive answers based on the same operational facts the team is using.

08

Do not automate a process nobody trusts

Integration can move a weak process faster.

If sales uses five different meanings for won, automatically creating a job will expose that confusion. If operations does not know which address is approved, synchronising both addresses will not decide. If finance depends on a spreadsheet that only one person understands, connecting it directly may turn a visible fragility into a hidden dependency.

Map the current journey before building. Follow a normal case and several awkward ones. Identify decisions, unofficial workarounds, data owners, approval points and the moment responsibility changes. Some manual steps exist because the software is poor. Others exist because a person is making a judgement that should remain visible.

Fixing the process may reduce the integration scope. A clear acceptance rule and one authoritative address can remove several branches from the design. The aim is not to automate every click. It is to make the important route dependable.

09

Sometimes a simple export is enough

Not every gap deserves a permanent live connection.

A low-volume monthly report may be safer and cheaper as a controlled export. A short-lived supplier handover may justify a checked file. Two products may already share an adequate native connector. A person may need to review each case because the consequence of a wrong decision is too high.

Avoid custom integration when the business cannot name the event, owner or useful result. Also pause when either system is about to be replaced, the supplier interface is unstable or the data is too inconsistent to map safely.

The smaller route is not a failure of ambition. It is good technical judgement. Use a manual check, standard connector or scheduled transfer while it remains proportionate. Move to a stronger connection when volume, urgency, risk or business value provides a clear reason.

10

Build the smallest dependable route first

Return to the maintenance business. The first version does not need to connect every customer, job, invoice and document in both directions.

It could begin when a quote reaches one agreed accepted state. The integration confirms the CRM customer ID, validates the required site and contact fields, creates one job, stores the job system identifier against the opportunity and shows an exception when any required value is missing. Duplicate events update the same record. Temporary failures retry. Unresolved cases appear in a review list owned by operations.

Test it with an ordinary quote, a duplicate event, a missing address, an unavailable job system and a customer that already exists under another trading name. Confirm that a person can understand and repair every failure without editing the database.

Once that route is stable, add the next valuable event. Job approval might prepare an invoice. A completed visit might release documents to a portal. Each addition should have a clear owner, evidence of success and a reason the business can explain.

System integration works when the applications support the same piece of work without hiding responsibility between them. Start with one repeated handover, decide which facts are authoritative and design the failure path before celebrating the automated one.

If staff are copying the same customer, job or finance information between systems, I can map the workflow, assess the available connectors and build the smallest reliable integration with clear ownership, monitoring and recovery.