Business event
What must the operation complete?
Define the trigger, outcome and acceptable delay.
APIs · Legacy systems · Identity · Migration · Reliability · Cloud operations
Connect systems without hiding the operational risk.
An integration is not complete when one API call succeeds. The operation must still know who owns each record, how identities are matched and who restores work after rejection or disagreement.
Twin Global designs APIs, migration, deployment and monitoring around those operating responsibilities, so teams can change and support the connected environment with confidence.
Integration begins with responsibility
Every interface is an operating agreement between systems and teams.
Define the business event, system of record, identifiers, visible state and recovery owner first.
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.
The simplest pattern that fits the dependency
Use clear contracts without unnecessary operational complexity.
The appropriate pattern depends on timing, volume, provider constraints and failure tolerance. Identity, validation, access, error handling and change ownership must be explicit.
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
A reliable integration explains how incomplete work is found and restored.
Rejections, outages, duplicates and partial completion need visible status and a controlled route to retry, correct, reconcile or escalate.
Confirm the business outcome, not only the technical response
A completed transaction remains traceable from trigger to final state.
A shared transaction identifier links the request, response, workflow status and user outcome.
- Contract and identity validated
- Final workflow state confirmed
Correct before retrying
A validation rejection should create owned work, not repeated failure.
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
An unavailable provider needs bounded retry, backlog visibility and escalation.
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
Assess, rehearse, coexist and reconcile before retiring the old operation.
Migration covers mapping, cleansing, configuration, acceptance, cutover and verification. Phased operation may be safer than one replacement event.
Stage 01
Understand the operating dependency before changing it.
Map owners, workarounds, integrations and source-data quality.
Stage 02
Define how every important record moves and changes.
Document fields, identifiers, transformation rules and ownership.
Stage 03
Prepare data, environments and operating procedures together.
Clean records, configure access and agree operational controls.
Stage 04
Rehearse timing, validation and correction before cutover.
Use representative volumes and exercise exceptions, not only successful records.
Stage 05
Control which system owns updates during coexistence.
Synchronise only where necessary and make temporary rules explicit.
Stage 06
Use one coordinated plan for versions, credentials and rollback.
Apply decision gates before the live operation changes.
Stage 07
Confirm transactions and workflows, not only record counts.
Resolve differences and verify the final business state.
Stage 08
Monitor the new operation before retiring old dependencies.
Track incidents, corrections and support ownership through stabilisation.
Deployment, monitoring and operational visibility
Move configuration, credentials and responsibility with the release.
Separate environments reduce accidental change. Controlled releases coordinate versions, interface contracts, provider windows and rollback.
Operational monitoring should show system health, transaction status, rejection reasons, queues and delays. Alerts need a named owner and enough context to act. Cloud choice alone does not guarantee security, resilience or compliance.
Contract and identity testing
Verify authentication, formats, validation, version behaviour and identity matching.
Volume and recovery testing
Exercise ordering, duplicates, retries, queue growth, downstream delay and reconciliation.
Cutover and rollback testing
Coordinate versions, credentials, provider windows, owners and rollback conditions in one plan.
Relevant product integration patterns
Connect each product according to the operational role it owns.
Twin CRM, PangoCDP and bespoke operational platforms may operate independently or together. Record ownership, consent and failure paths must remain clear.
Twin CRM
Connect websites, portals, mobile applications, ERP, dealer systems, messaging, PangoCDP and reporting while preserving ownership of customer and service records.
Explore Twin CRMBespoke operational platforms
Connect finance, payments, access, maintenance, resident applications, leasing workflows and reporting around clearly defined property-operation responsibilities.
Platform and workflow engineeringPangoCDP
Connect CRM, commerce, point-of-sale, applications, messaging and reporting with explicit identity, consent, data-quality and failure handling.
Explore PangoCDP
Australian integration work in practice
ScriptStream: external services, environments and recoverable workflow states
Twin Global Solutions completed integration and production-readiness work covering Healthcare Identifiers integration, eRx interfaces, certificates, credentials, test and production environments, rejection handling, retries, correction paths, status visibility and end-to-end testing.
The wider programme also includes PRODA-related access work, with full PRODA integration still underway. The customer story contains the complete milestone record and current production status.
View the ScriptStream customer storyMap systems, ownership and failure risk
Discuss the integrations your operation must be able to support.
The discussion should cover the systems, dependencies, migration constraints and failure scenarios that matter.