Integration
Integrations between the business systems an organisation already runs, built so information and processes move reliably, failures are visible and someone is responsible for the result.
Most organisations already have systems that work well enough on their own. The operational trouble sits between them: staff export, tidy and re-enter the same information, and a missed step shows up later as a wrong invoice or a record two systems disagree about.
What we offer
API Development
Reliable, documented APIs for organisations whose systems need to exchange data or trigger each other through a stable interface, whether that means building a new one or repairing an existing one.
Automation
Automation of repeatable business and technical processes where the rules can be written down, with exceptions and human review points designed in from the start.
Robotic Process Automation
Automation that works through an application's own screens, the way a person would, for systems that have no suitable API or other direct integration. Used when a supported integration is unavailable or impractical, and built with monitoring and clear points for people to step in.
Ownership, failure and operation
Moving data between two systems is often the visible part of the job. Many integration problems come from decisions that were never made: which system is authoritative for a given record, what should happen when a transfer fails halfway, and who is told about it. Without those decisions, a connection can work in testing and then drift, until two systems disagree about a customer, an invoice or a status.
Before choosing a transport method, we follow the manual process as it actually runs. It usually contains rules nobody has written down. Then we choose a practical way to connect the systems, such as an API, a file, a scheduled job or an event, and design retries, reconciliation, access control and documentation so someone other than the original developer can operate it.
How we treat an integration
Named ownership
Each important record type should have an authoritative system. Other systems can hold copies, but it should be clear where updates originate and how conflicts are resolved.
Credentials that can be revoked
Each connection should have its own account and only the permissions it needs, so one integration can be changed or removed without affecting the rest.
Retries that do not create duplicates
Where a transfer can be repeated, the design should use identifiers so a retry updates the same record rather than creating another.
Failures that can be seen
Transfers should be logged, retried when the problem looks temporary, and reported to someone able to act when they keep failing. The exact alerting arrangement is agreed for the engagement.
Notes for whoever maintains it
Each connection should be documented: what it does, what it depends on and how to change it.
How a typical engagement works
01Mapping
Map the process as it runs
We follow the manual process, including exceptions and workarounds, and list every system, record and person it touches.
02Ownership
Agree who owns what
For each important record we settle which system is authoritative, how conflicts are resolved and what happens when a transfer fails halfway.
03Build and test
Build and test against real failures
The integration is built in stages and tested on real data, including duplicates, partial transfers and a system being unavailable.
04Handover
Hand over something operable
Credentials, alerting and documentation are set up so someone other than the original developer can run and change it.
05Support
Support as systems change
After handover, support can continue in the background as the connected systems change and new integrations are needed.
Evidence
Insights
- When an integration platform is enough, and when custom integration is worth building
Zapier and Power Automate can be the sensible way to connect systems when the workflow is clear and failure is easy to recover from. Custom integration becomes more attractive as state, reconciliation, throughput and operational consequences become harder to leave inside a platform abstraction.
- What to establish before an integration project starts
Before connecting two systems, an organisation needs to know which one owns the information, what should cause it to move, what happens when a transfer fails, and who is responsible once the integration is part of daily work.
- After 1 July 2026: AML/CTF in the systems firms already use
From 1 July 2026, specified legal, accounting and real-estate services sit inside the Commonwealth AML/CTF regime. This brief looks at what that means for the systems those firms already use, and what they should now be able to see and record.
Frequently Asked Questions
Start with a conversation
Book a free 15 minute call. Describe the problem, the systems involved and what you already know, and we will tell you plainly whether we can help and what a sensible next step looks like. There is no obligation.