Business event
What must the operation complete?
Define the trigger, outcome and acceptable delay.
APIs · Legacy systems · Identity · Migration · Reliability · Cloud operations
Stop re-entering records between systems.
Reduce the time your teams spend copying, checking and correcting the same record. Twin connects existing systems so an order, customer update or completed job can reach the next team with its status intact.
Start with one exchange. Its scope identifies the source and destination, update timing, failure owner and the evidence your team will review before the connection goes live.
Integration in use
Dealer orders linked to SAP DMS
Twin connected Mitsubishi Motors Vietnam’s sales and service CRM applications to its SAP Dealer Management System. Salespeople could work on dealer orders from the web CRM and salesperson app, with the dealer system’s reference visible on the order.
In an Australian regulated setting, Twin connected ScriptStream with external health services. The project was in early production in October 2026, with full PRODA integration still underway.
See Mitsubishi’s sales and service integration · Check the ScriptStream milestones
Before systems exchange data
Define one exchange your team can rely on.
Follow a representative record from its source to the receiving team. Agree the completed business action, then test a valid exchange, a rejection and a recovery before extending the scope.
System of record
Which system owns each record?
Name who may create, update and correct the record.
Identity
How are people, accounts and assets matched?
Control identifiers, duplicates and access.
Visible state
What does the user see while systems differ?
Show waiting, completed, rejected and corrected states.
Recovery owner
Who restores the business process?
Assign alerts, retries, reconciliation and correction.
Australian integration work in practice
ScriptStream: Australian health services and integration testing
For Wesley Pharmacy Group’s ScriptStream, Twin connected the prescribing workflow with Australian health services and tested external responses, rejected requests and correction paths. Users needed a visible status and a permitted next action when an exchange did not complete.
The October 2026 record shows early production, with full PRODA integration still underway. The story sets out the specific completed milestones.
View the ScriptStream customer storyClient work
Connected systems behind a working customer service.
Each example has its own source systems, information flow and operating purpose.
CRM and SAP DMS
Mitsubishi Motors Vietnam
Sales and service applications, vehicle-owner experiences and SAP Dealer Management System integration formed part of the Mitsubishi Motors Vietnam programme.
Read the customer story
Service CRM and field applications
Unilever Pureit
Customer requests, technician assignment and field updates connected the service team with the work in progress.
Read the customer story
PangoCDP customer data flow
Nutifood
Nutifood’s published PangoCDP account describes sampling, customer journeys and a Salesforce CRM data flow.
Read the customer storyThe simplest pattern that fits the dependency
Choose the connection that fits the timing and volume.
An immediate API request, a queue and a scheduled file transfer solve different problems. We assess the required response time, expected volume, provider limits and the effect of a delay.
Use when the next step genuinely depends on an immediate result
Direct API
Define authentication, required data, validation, version behaviour, time-outs and provider failure responses.
Use when systems need independence and resilience
Events and queues
Design for ordering, duplicates, backlog visibility, failed messages and final-state reconciliation.
Use when the surrounding environment requires it
Scheduled exchange
Define the schema, cut-off time, transfer, acknowledgement, late-file ownership and reconciliation.
Use when immediate replacement would create unnecessary risk
Legacy adapter
Stabilise the interface while selected workflows and data move into a maintainable platform.
Design the normal path and failure path together
Find incomplete exchanges and recover them safely.
If a dealer order is rejected because its customer reference is missing, show the rejected status and route it to sales operations. The person handling it checks the customer and order in the dealer system, corrects the record, then confirms whether the receiving system accepted it. If it already exists there, reconcile the record before any retry.
Confirm the business outcome, not only the technical response
Confirm that the receiving system completed the work.
A shared transaction identifier links the request, response, workflow status and user outcome.
- Contract and identity validated
- Final workflow state confirmed
Correct before retrying
Give a rejected request to someone who can correct it.
Show the reason, prevent duplicates, route correction to an authorised person and confirm the final state.
- Clear rejection reason and owner
- Correction path with traceable history
Queue safely and stop when human judgement is needed
Limit retries and show requests waiting for a provider.
Retry only when a request is safe to repeat. Set limits, prevent duplicates, monitor the queue and reconcile incomplete transactions.
- Safe retries and duplicate prevention
- Retry limits and delayed processing
Modernise without treating migration as a data copy
Rehearse the migration before changing the live service.
Migration includes mapping and cleaning records, preparing environments, user acceptance and checking the live transfer. Some services need a period with both systems running.
Stage 01
Map the systems and work that depend on the data.
Map owners, workarounds, integrations and source-data quality.
Stage 02
Document how records will be mapped and transformed.
Document fields, identifiers, transformation rules and ownership.
Stage 03
Prepare the records, access and environments.
Clean records, configure access and agree operational controls.
Stage 04
Test the transfer with realistic volumes and errors.
Use representative volumes and exercise exceptions, not only successful records.
Stage 05
Agree where updates are made while both systems run.
Synchronise only where necessary and make temporary rules explicit.
Stage 06
Coordinate the live change and the rollback plan.
Apply decision gates before the live operation changes.
Stage 07
Check that records and business tasks agree.
Resolve differences and verify the final business state.
Stage 08
Stabilise the service before retiring the old system.
Track incidents, corrections and support ownership through stabilisation.
Release and operational support
Prepare the software and the people who will operate it.
Cloud engineering brings environments, deployment, access and monitoring into the delivery programme. Agree how the service will be released, supported and improved as its connected systems change.
Contract and identity tests
Verify authentication, formats, validation, interface versions and identity matching against the connection’s agreed behaviour.
Volume and recovery tests
Exercise ordering, duplicates, retries, queue growth and downstream delays. Reconcile incomplete transactions and confirm that safe retries do not create repeated work.
Cutover and rollback tests
Coordinate versions, credentials, provider windows and named owners. Rehearse the conditions for stopping or recovering before changing the live service.
Monitoring should show application and infrastructure health alongside transaction status, rejected records, queues and delays. Each alert needs an owner and enough business and technical context to investigate.
Connected customer and operational software
Connect the selected products with their operating context.
Twin CRM, PangoCDP and tailored platforms can exchange relevant customer, transaction and service information with existing systems. The scope follows the available interfaces and each system’s responsibility.
Connections can span websites, portals, mobile applications, ERP, dealer systems, messaging, commerce, point of sale and reporting. Property programmes may also connect leasing, finance, payments, access, maintenance and resident services.
Before we begin
Scoping the connections
Can you connect legacy systems as well as modern APIs?
Yes. The available interface and operating constraints determine the design. A programme may use direct APIs, events, scheduled file exchanges or an adapter around a stable legacy system. The selected approach is tested against the business need.
How do teams know an exchange has failed?
The integration design defines the expected result, validation, monitoring and correction path. A rejected record or unavailable provider should be visible to the responsible team, with a safe way to resolve or replay the exchange where appropriate.
Does migration require an immediate replacement of the old system?
The migration plan can include assessment, mapping, preparation, rehearsal and a period of coexistence. Cutover, reconciliation and support arrangements are agreed around the service’s dependencies and release needs.
Map systems, ownership and failure risk
Discuss the systems you need to connect.
Bring the record your team enters twice, the systems involved and a recent failed handover. We can define a first connection and how your team will check its result.