Software integration · Ireland · Delivered from Spain
Connect your tools with clear ownership of the data.
When the same details are copied into several systems, a connection alone does not settle which record is correct. A useful integration needs a source for each field, a person responsible for its quality and a clear response when the transfer fails.
Intelidatia designs and builds custom operational systems. We work remotely from Spain, in English, with Irish teams. We first assess your existing software and available interfaces; the scope of any connection depends on its access, permissions and data.
Agree who maintains each piece of information
“The CRM owns the customer” is often too broad. Sales may maintain a contact name while another team controls the reference needed to start work. Decide ownership field by field where responsibilities differ.
For each transfer, agree the source system, destination, record identifier, responsible person and validation rule. Also decide whether information moves one way or both ways. Two-way synchronisation needs explicit rules for conflicting changes; it should not be assumed because two tools both allow editing.
A handover between two systems
Illustrative example — synthetic process, not a delivered client integration. A service team wants approved job details from its customer-management system to appear in an operations work queue. The systems, fields and recovery steps below illustrate decisions to scope. No named connector or production implementation is implied.
| Information | Authoritative record | Responsible team | Direction and rule |
|---|---|---|---|
| Customer reference | Customer-management system | Sales operations | Copy the stable reference to the work queue; hold unmatched references for review. |
| Approved job scope and version | Approved job record in that system | Operations approver | Transfer only the approved version. A later change must be reviewed before replacing it. |
| Delivery status | Operations work queue | Delivery coordinator | Keep status ownership here. Any return update requires a separately agreed mapping. |
| Transfer status and error reference | Integration record | Named integration owner | Show pending, completed or needs attention; link both record identifiers when available. |
For this example, the desired trigger is approval of a job. Whether the actual connection can use an event, a schedule or an import depends on the interfaces available. Agree how much delay the team can tolerate before selecting the approach. Do not promise real-time synchronisation without checking that requirement and the systems involved.
Make unsuccessful transfers visible
Missing or invalid data. Hold the transfer for the responsible team to correct the source. Repeating the same request will not repair a missing customer reference.
A temporary outage or service limit. A scoped recovery policy could wait and retry a limited number of times, where the destination supports safe repetition. If recovery does not succeed, the integration owner needs a visible record and next action.
The destination may have accepted the record, but no confirmation arrived. Treat the result as unknown. Check for an existing destination record using the agreed reference before creating another. A repeat attempt must not be assumed safe: duplicate prevention depends on the destination and must be designed and tested.
Access has expired or permissions have changed. Pause the affected transfer and route it to the person responsible for access. Repeated retries are not a substitute for restoring permission.
The team should be able to distinguish a completed transfer from a queued or uncertain one. Monitoring responsibility, support arrangements and recovery times belong in the agreed scope; no round-the-clock service is implied.
Check the existing connector first
A native connector may already cover the required fields, direction, permissions and failure handling. An automation platform may cover the remaining steps. Custom integration is an option when a necessary part of the operation remains unsupported and the value justifies building and maintaining it.
Before recommending a build, assess a representative record, access requirements, supported operations and expected changes to the source systems. Agree acceptance checks for missing data, a temporary outage, a repeated request and a conflicting update. These are proposed checks for a future scoped connection; they are not results from an integration already delivered.
Compare custom and off-the-shelf approaches. If the unresolved issue is who can approve the work, see workflow automation.
Evidence from connected operational systems
For Zeus Fisioterapia in Spain, we built a public website, guided booking and a private panel for appointments, patients, professionals, services and schedules. For CD Novés in Spain, we connected member administration, signed QR cards and mobile access scanning within its system.
These projects demonstrate connected public and private workflows and operational records. They do not demonstrate the third-party integration illustrated above, an accounting connector or an Irish client result.
Start with the transfer that causes the most friction
Tell us which two tools are involved, what the team copies between them, who maintains that information and what happens when it goes wrong. Use a description or invented example rather than sharing customer data or credentials.
Start with a free 20-minute fit conversation. We reply in English within two business days. If the systems or responsibilities need further investigation, we may recommend the Operational Workflow Sprint. Its purpose is to map the operation and define the next phase; it does not include full development, live data migration or production automation.
Review the sprint scope, price and exclusions.
Discuss your integration workflow