Connect business software by defining the record that needs to move, which application owns it, what event triggers the transfer, how fields are mapped and validated, and what happens when the transfer fails. The connector itself is only one part of the integration.
Most businesses do not have a shortage of software.
They have a problem in the spaces between the software.
The CRM has one version of the customer. Finance has another. Operations has the information it needs to deliver the work, but somebody copied it there from an email three days later.
A connector can move data between those systems. But if the business has not decided which record is correct, what should move, and who owns failures, the connector may only automate the confusion.
1. Map the handoff first
Begin with the work employees are doing manually.
- Where does the information begin?
- Who creates or approves it?
- Which fields does the next team need?
- What event should move it?
- What do employees copy, reformat, or check today?
- What happens when the information is missing or wrong?
This reveals whether the actual problem is connectivity, inconsistent process, poor information, or unclear ownership.
Do not start by asking, “Can these two tools integrate?”
Start by asking what business handoff the connection is supposed to improve.
2. Name the system of record
For each important record—customer, invoice, order, project, employee, product, service request—decide which system owns the authoritative version.
Other applications may use or enrich the record, but one source needs to be responsible for each field that matters.
Two-way synchronization without ownership rules can multiply conflicts instead of resolving them.
If a customer address changes in the CRM and finance system at the same time, which one wins? If nobody can answer, the integration design is not finished.
3. Choose the appropriate connection method
| Method | Best fit |
|---|---|
| Native integration | A common connection where the available fields, rules, security, and monitoring are sufficient |
| Automation platform | A defined workflow across supported systems with moderate complexity |
| API or webhook | Custom rules, event-driven updates, near-real-time transfer, or deeper control |
| Scheduled file exchange | Batch movement where real-time transfer is unnecessary |
| Custom integration service | Complex logic, unsupported systems, higher scale, or special security and reliability requirements |
Use the simplest method that can meet the operating requirement reliably.
A native connector is useful when it does the job. Custom software is justified when the required rules, controls, or systems genuinely cannot be handled another way.
4. Define mapping and validation
The integration design should state:
- which fields move;
- which format each system expects;
- which fields are required;
- how duplicates are identified;
- how updates and deletions are handled;
- which business rules must pass before a record is accepted;
- what information must not cross the connection.
Field mapping is not administrative detail. It is where different systems' definitions meet.
“Customer,” “active,” “completed,” and “revenue” can mean different things in different applications. Those definitions have to be resolved before they can be synchronized.
5. Design for failure
Connections will eventually encounter missing fields, expired access, duplicate events, vendor outages, changed schemas, rate limits, and unexpected values.
Define what happens before launch:
- Which failures should retry automatically?
- Which ones require a person?
- Where can employees see the failed item?
- Who owns the exception queue?
- How is the source reconciled with the destination afterward?
- How long can the transfer wait before the business is affected?
Silent failure is not an acceptable operating model.
6. Test real cases
Test normal records, incomplete records, duplicates, corrections, cancellations, deleted items, permission failures, delayed events, and replayed events.
Employees should be able to see what happened and recover without reading code.
If only a developer can tell whether the integration worked, the operating design is incomplete.
Integration design worksheet
| Field | Decision required |
|---|---|
| Business handoff | What work should move faster or require less manual effort? |
| Source record | Where does the information begin? |
| System of record | Which application owns each important field? |
| Trigger | What event starts the transfer? |
| Mapping and validation | What moves, in which format, and under which rules? |
| Exceptions | What can fail, where is it shown, and who resolves it? |
| Monitoring | How will delays, duplicates, rejection, and incomplete transfer be detected? |
| Ownership | Who approves, maintains, and changes the integration? |
At Losung Consult, we design and implement integrations around the business handoff, not around the connector.
Tell us which systems should already be talking and what employees currently do to bridge the gap. That is normally the best place to start.