A native connector is an app or setting offered by one of the vendors. Middleware is a separate integration platform that runs flows between systems. A custom integration is code your team or a partner writes and hosts. Custom code can itself act as middleware when it sits between several systems.
The options can work together. A native connector can sync customers while custom code handles one complex order rule.
Before you compare options, agree which system owns each field and which identifiers link the records. The requirements below depend on those decisions.
Decide when a process needs orchestration
An orchestration runs a whole business process across several systems. One business event starts a run. The orchestration tracks where each run is and handles waits, approvals and failures.
Point-to-point syncs are enough when each flow copies records between two systems and no flow depends on another. Consider orchestration when a process shows one or more of these signs:
- One event drives steps in three or more systems.
- Steps must happen in a set order.
- A step waits hours or days, for example for an approval, a payment or a signed document.
- A later failure means undoing earlier steps.
- Someone needs to see where every run is.
An orchestration can also run processes that involve people as well as systems. For example:
- Onboard a new customer. Create the accounts, assign an onboarding owner, wait for the kick-off meeting, then send the first tasks.
- Handle a contract change. Update the subscription, adjust the next invoice and tell the account owner.
- Approve a large discount. Send it to a manager, escalate it if nobody responds in two days, then update the quote.
- Run month-end steps. Close billing, run the reconciliation and send the reports once each check passes.
Check what the orchestration layer must do
- Order. It runs steps in order, and in parallel where they do not depend on each other.
- Branches. It takes a different path based on a condition, such as credit approved or declined.
- Waits. It pauses for a person or an outside event, with a timeout and a step to take when it expires.
- Retries. It retries a failed step with increasing gaps, up to a maximum number of attempts.
- Undo steps. When a later step fails for good, it runs compensating steps that undo earlier work. A process across several systems cannot simply roll back.
- Run history. It records each run's status and step history.
- Safe repeats. Each step is safe to repeat. See duplicate-safe replay below.
- Versions. When the process changes, runs in progress finish on the version they started with.
Example (illustrative): an accepted quote in the CRM starts a run. All times and counts are illustrative.
| Step | System | Waits for | If it fails |
|---|---|---|---|
| 1. Create or match the customer | ERP | The accepted quote | Retry, then alert. |
| 2. Create the sales order | ERP | Step 1 | Retry, then alert. The customer record can stay. |
| 3. Raise the first invoice | ERP | Step 2 | Retry, then cancel the sales order. |
| 4. Wait for payment or credit approval | ERP and a credit approver | Payment or a decision, for up to 5 business days | On a decline or timeout, void the invoice and cancel the sales order. |
| 5. Provision the service | Provisioning system | Step 4 | Retry, then credit the invoice, cancel the sales order and refer any payment to finance. |
| 6. Update the quote with order and service status | CRM | Step 5 | Retry, then alert. Nothing is undone. |
In this example, each retry allows up to 5 attempts, with gaps of 1, 2, 4 and 8 minutes. Undo steps need their own retries and alerts, because a cancellation can fail too.
A connector or custom code can still carry out a single step. The orchestration layer decides the order, the waits and the recovery.
Write down what the integration must do
Start with requirements. Without them, the choice tends to follow whichever option someone already knows.
Example (illustrative): a business sends accepted quotes from a CRM to an ERP as sales orders, then invoices and provisions them. Fill in the same questions for your integration.
| Question | Example answer |
|---|---|
| Which systems are involved? | CRM, ERP and a provisioning system. An online store may join next year. |
| Which records move, and in which direction? | Customers and orders from CRM to ERP. Invoice status from ERP to CRM. |
| How many records each day, at peak? | About 200 orders on a normal day, 1,500 at end of quarter. |
| How fast must a change arrive? | Orders within 15 minutes. Invoice status overnight is fine. |
| What has to change on the way? | Map CRM product codes to ERP item codes. Split one deal into several order lines. |
| Does the order of changes matter? | Yes. A customer must exist in the ERP before its first order arrives. |
| What happens to cancellations and deletes? | A cancelled order updates its status in the CRM. Deleted customers are reviewed by hand. |
| What is the matching key? | ERP customer ID stored on the CRM record. ERP order ID stored on the CRM order. |
| Which steps run across systems, in what order? | Customer, sales order and first invoice in the ERP. Provisioning after payment or approval. Then a CRM update. |
| Which steps wait, and for how long? | Payment or credit approval, for up to 5 business days. |
| What is undone if a later step fails? | If provisioning fails, credit the invoice and cancel the order. |
| Who tracks each run? | Sales operations sees each run's status. A named person handles stopped runs. |
| Who will support it? | One systems administrator. No in-house developers. |
Understand what each option involves
Native connector
You install it and configure it through settings. The vendor maintains it and updates it when either system changes. Some connectors offer fixed mappings only. Others support transformations, filters and business rules. You work within the features, timing and error handling it provides.
Middleware
You build each flow on a separate integration platform, often with visual steps and some scripting. Many platforms offer scheduling, retries and logs, but features vary by plan. Your team or a partner builds and maintains the flows, and you pay for the platform.
Custom integration
You write code against each system's API and host it yourself. You control every rule. You also own every failure, upgrade and security patch.
Compare the options against your requirements
This matrix describes common patterns, and individual products vary. Check each point against the product you are considering.
| Criterion | Native connector | Middleware | Custom build |
|---|---|---|---|
| Transformation | Check the connector's supported mappings, transformations and business rules. | Mapping, lookups and conditional logic, within the platform's features. | Any logic you can write and test. |
| Number of systems | Usually the two systems it was built for. | Several, managed in one place. | Any, but each adds code to maintain. |
| Retries, logs and recovery | Verify what the connector provides. | Verify what the platform and plan provide. | Whatever you build and run. |
| Support ownership | The vendor, for the connector itself. | Your team or partner, plus the platform vendor. | Your team or partner only. |
| Skills needed | System administrator. | Integration specialist. | Developer and someone to host and monitor it. |
| Ongoing cost | Licence or included in a plan. | Platform fee plus build and change work. | Hosting plus developer time for every change. |
Reject any option that fails a mandatory requirement. Compare the rest on support, total cost and maintainability. Compare total cost over the same period for each option, including build, licences, hosting and change work.
Check transformation and capacity
- Transformation. List every rule that changes data on the way. If a rule needs a lookup or a condition, ask the vendor whether the option supports it.
- Capacity. Capacity depends on the product, the plan, each system's API and the design. Ask the vendor or partner how the option handles your peak day, and get the answer in writing.
Every option has to work within each system's API limits, including a custom build.
Check how each option handles failure
Treat each of these as a capability to verify. Ask for a written answer, then test it.
- Retries. Failed requests are retried automatically, with a set number of attempts.
- Duplicate-safe replay. Retrying a request does not create a second order or payment. This property is called idempotency.
- Ordering. Changes to the same record arrive in order, or an older change cannot overwrite a newer one.
- Deletes and cancellations. You know what the option does when a record is deleted or cancelled. Some sync creates and updates only.
- Recovery. Failed records are kept and can be replayed after a fix.
- Logs. Logs show what changed, when and in which direction.
- Monitoring. Alerts include the record ID and the reason. An alert also fires when the sync stops running.
A common way to make retries safe is to send a unique key with each create request. The receiving system then recognises a repeat and returns the first result. For further reading, see Stripe's post on idempotency.
Also check security and data location before you sign or build.
- Credentials sit in a secure store and use the least access that works.
- You know where the platform or hosting stores data, if your obligations require data to stay in a region.
Decide who supports it
An integration needs someone to watch it after go-live. Choose an option your team can support, even if another option meets more requirements.
| Task | Owner (example) |
|---|---|
| Works the alert queue each morning | Systems administrator, with a named backup |
| Changes mappings when a field is added | Systems administrator or integration partner |
| Fixes faults in the integration itself | Connector vendor, middleware partner or developer |
| Reviews the integration after each system upgrade | Systems administrator |
Data errors in a field go to the team that owns it, as set in your field ownership table. A custom build with no developer to maintain it becomes a risk the first time an API changes.
Test the shortlist at peak load
Run a proof of concept before you commit. Use a sandbox or test environment loaded with production-sized data, with personal information masked.
- Load a full day of peak records and time the sync.
- Include records with missing keys, long text and unusual characters.
- Make one system unavailable for an hour, in the test environment or with a simulated outage. Check that records queue and then catch up in order.
- Send the same create request twice and confirm that only one record is created.
- Cancel and delete test records, and check the result in the other system.
- For an orchestrated process, make the last step fail and check that the undo steps run.
- Confirm the alert reaches the named person with enough detail to act.
Check the test results record by record, using the method in reconciling ERP, finance and CRM data.
Plan the discovery work
Here is an example two-week discovery schedule. It assumes you have system access and that vendors reply within a few days. Allow more time if they do not.
- Week 1: Complete the requirements template with each team. Confirm ownership, identifiers and peak volumes. Shortlist one or two options.
- Week 2: Get written answers from the shortlist and run the proof of concept. Agree the option and the support owner.