Standard connector or custom integration: test the whole process

Start with a minimal business process

Describe one event with a definite beginning and end. For example, an employee approves a quotation and a draft project is created with the correct customer reference. Identify prerequisites, the expected destination state and the person who checks the result. Avoid beginning with every possible future application when the first useful route remains unclear.

A connector might use a different sequence, such as creating a project for every new quotation. That is consequential when rejected quotations then produce unwanted records. Decide whether the business process can responsibly change. Sometimes a simpler internal procedure is more valuable than software reproducing every historical exception. The operational owner should approve that trade-off explicitly, rather than discovering it after the connector is introduced.

Check the meaning behind available fields

A customer-number field may be a controlled business identifier in one product and an editable reference in another. Status, balance and delivery address can hide similar differences. Check what each field means, who changes it and what happens when it is empty. A demonstration using deliberately identical sample data can obscure precisely the mismatch that causes difficulties later.

Map five consequential fields, recording source, destination, transformation and handling of invalid values. A translation boundary can help where the models differ substantially. Microsoft describes that architectural approach in its Anti-Corruption Layer pattern. The existence of a pattern does not establish that more custom code is desirable. Check first whether the candidate connector already performs the necessary translation clearly and sufficiently.

Microsoft Azure Architecture: Anti-Corruption Layer ↗

Run a small suitability trial

Use a test administration containing a normal business customer, multiple contacts, a missing mandatory code and a changed invoice address. This fictional set should represent relevant exceptions without copying personal records unnecessarily. State the expected result before running each example. Then test repeated submission and temporarily making the destination unavailable, since those situations reveal different weaknesses.

Do not judge the trial solely by a green execution indicator. Find the destination record, check the meaning of amounts and dates, and inspect the message an employee receives. Record what is configurable without programming, what needs extension and what is unsupported. Those three categories support a concrete decision without pretending that a limited trial has covered every future scenario or vendor change.

Compare the same scope and recurring work when choosing an approach. This guide explains the cost structure: What does an API integration cost? Define the job before the price.

Compare three solution types

A connector generally offers a predefined route between products. An integration platform supplies components for building rules, either internally or with a specialist. Custom implementation develops the necessary processing for your requirements. Actual products can combine these approaches. Ask how the solution runs and who owns each responsibility, rather than deciding from the label used in a sales description.

A platform workflow remains your design when you choose filters, fields and retry behaviour. The platform provider may have no knowledge that a second draft invoice violates a business rule. Conversely, custom work need not mean replacing everything: a small translation component around an existing connector may suffice. Compare the simplest option that demonstrably handles the agreed cases and can be understood by its future maintainers.

Investigate exceptions and recovery

Ask what happens when access expires, a field is invalid or a destination is unavailable for an hour. Can an employee resubmit one item? Can they see which actions have already occurred? Restarting the entire workflow may have unwanted consequences when a customer, project or document was already created before a later step failed.

Also establish how a missed event becomes visible. A connector showing errors only for received messages can remain silent when an event never arrives. A periodic comparison of business references or expected counts may be needed. Assign that checking responsibility. Recovering the operational workload is often a more useful differentiator than the number of application icons in a vendor’s catalogue or the speed of a successful demonstration.

Compare costs over the same period

For each candidate use the same time period and workload. Include setup, subscriptions, transaction charges, hosting, human review and agreed support. Model low, expected and higher volumes. Use actual supplier quotations and current terms instead of inventing a market average to make a preferred technology appear attractive. State which costs are confirmed and which depend on unresolved assumptions.

Include foreseeable changes, such as another administration, a new field or a second order type. Ask which are configurable and which require development. A low initial cost may suit a temporary trial. A critical operational process may justify more initial work if it demonstrably reduces support effort or dependence. Connect that expectation to specific tasks and evidence instead of treating custom code as inherently a better long-term investment.

Decide who can operate the solution

A connector may contain little code yet depend on one administrator account with extensive permissions. Custom code may be transferable or understandable only by its original developer. Ask about configuration export, documentation, account ownership, log access and the ability to appoint another maintainer. These practical details determine continuity more directly than the language in which the integration was written.

Have a colleague perform a small support task using the instructions, such as investigating a failed item without modifying records. Record missing information. Check what happens when a subscription ends: whether records remain accessible, workflows need replacement and access must be revoked. Transferability should be demonstrated while alternatives remain available, before the organisation becomes completely dependent on an undocumented connection and one person’s knowledge.

Record the decision and review triggers

Write the decision as a bounded assessment: this option supports these events, these exceptions remain manual and this owner monitors the result. Attach the trial evidence. Record why an alternative was rejected, such as missing fields or unclear recovery. A future team can then identify the assumptions behind the choice rather than trying to reconstruct an undocumented discussion.

Define practical reasons to revisit the decision. They might include a new process, changed vendor access or a growing amount of manual exception handling. An initial connector does not need to become the permanent architecture for every application. Start with a manageable flow, measure actual exceptions and extend only when the problem is clear. A successful choice is one the team can understand, operate and responsibly adapt as circumstances change.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• API integration ↗
• CRM integration ↗

Questions about this topic

Continue with a related question