Industry
Part of 9 pointers on software integrations that hold up
Software integrations tools: seven tests for one workflow
Software integrations tools judged by a test you run: seven checks on one real workflow, plus questions on rate limits, pricing units and change notices.
A demonstration shows a connection working and skips what happens when it fails. So the test is to build one real workflow, currently done by hand, in each candidate, then break it on purpose. The result is yours to read, because fit depends on your workflow. Slack's Google Drive integration is one concrete product-to-product connection to check before building anything.
If built-in options do not cover the workflow, examples of connection platforms to evaluate include Zapier, Make, and Microsoft Power Automate. This is not a ranking, and fit depends on the exact workflow.
What to take away
- Evaluate by building the same real workflow in each candidate, including the part where it fails.
- A connection that produces duplicates under retry will eventually produce them at scale. Ask how it prevents them.
- Ask what the platform does when the far end refuses requests, and how a run is priced.
- The cost of a connection is not the build. It is who notices when it stops and who is allowed to fix it.
When a platform is even on the table
A platform belongs on the shortlist only after the cheaper shapes fail. Native connectors come first, scheduled exports second, a platform third, and custom code last. Move down the list only when the one above genuinely fails.
The options that skip a build entirely are laid out in software integrations alternatives.
Four integration shapes compared
Native connector
- What it is
- Built-in link
- When right
- Check first
- Needs developer
- No
- Typical outcome
- Often sufficient
Scheduled export
- What it is
- Timed file transfer
- When right
- Reporting, backups
- Needs developer
- No
- Typical outcome
- Nightly job
Connection platform
- What it is
- Runs many links
- When right
- Many, changing links
- Needs developer
- No
- Typical outcome
- Invisible to sellers
Custom code
- What it is
- Written to interfaces
- When right
- One vital connection
- Needs developer
- Yes
- Typical outcome
- Fits nothing else
For a small number of stable connections, a platform may be more than you need. Most organizations discover, after doing this honestly, that they need two native connectors and one nightly export. That is a good outcome, and it is invisible to anyone selling a platform.
Seven tests on one real workflow
Pick one workflow somebody currently does by hand, and build it in each candidate. The tests below expose failure handling and maintenance needs that a demonstration can gloss over.
Seven-step build test
- Build happy path, time it
- Break it with missing field
- Find the failed item
- Fix and replay one item
- Send same record twice
- Rename source field
- Hand workflow to colleague
- Build the workflow end to end with real records, and watch it succeed once.
- Send the same record twice, and check that no duplicate appears.
- Pause the source system for two hours, and note whether the platform queues, retries or drops.
- Feed it a record the far end rejects, and see where the failure shows up.
- Read the run history afterward, such as Zapier's task history or Make's scenario history.
- Hand the workflow to a colleague, and see whether they can read it.
- Disable the account the connection runs under, and see what breaks.
The second test matters most. A connection that produces duplicates under retry will eventually produce them at scale, and the plain definition of an idempotent operation is a good five minute read for anyone specifying this work without writing it.
The sixth test matters because a workflow only one person can read is a workflow with an expiry date attached to that person. Maintenance is part of the price, and it is invisible in a demonstration.
Questions the demonstration will not cover
Put these to the supplier before trusting the demonstration.
- What happens when the source system is unavailable for two hours: does the platform queue, retry, or drop?
- How many times will it retry, and with what spacing?
- Where do failures appear? Test whether an alert reaches a person rather than a dashboard nobody opens.
- How is a run pricedper operation, per record, per connection, or per month?
- Whose credential does the connection use, and what happens when that person leaves?
- What does the platform do when the far end starts refusing requests because you are sending too many?
Questions demos skip
- Source down two hoursqueue, retry, drop?
- How many retries, what spacing?
- Where do failures appear, who is told?
- Priced per operation, record, connection, month?
- Whose credential, what if they leave?
- What happens when far end rate limits?
The last one is routine and worth understanding rather than hoping about, since a rate limit is a normal response rather than an error. Ask specifically whether the service returns HTTP 429 ("Too Many Requests") and a Retry-After header, and whether the integration respects that retry hint.
The credential question is the one that causes real incidents. A connection running under a departing employee's account fails at the worst moment, or worse, keeps working and gives that account a reason to stay open. The full treatment of ownership is in software integrations that hold up, and the administration layer is where it gets settled.
Interfaces you do not control
Every connection depends on an interface owned by somebody else, and those change. Ask each supplier what notice they give before a breaking change, whether old versions keep working during a transition, and where the change log lives.
Then apply the same standard to whatever you build. Naming versions, documenting fields, and keeping a change log are the boring practices that make a connection survivable. They are set out in a compact form in the published API and data standards used for public services.
The OpenAPI Specification is a named format for describing APIs and their operations. Where connections cross security boundaries, use OAuth 2.0 for delegated authorization, OpenID Connect for authentication and identity, and the OWASP API Security Top 10 for common API risks.
What the decision comes down to
Three things settle it. Whether the two products you care about already talk to each other, which makes the question moot. Whether the people building the connections can do it without a developer, which is the honest reason platforms exist. And whether anybody will notice when a connection stops.
What the decision comes down to
Do the two products already talk?
question is moot
compare account administration
That third one is the test nobody applies. A connection with no owner and no alert is a scheduled outage nobody has written down yet.
Common questions
Is a no code platform genuinely usable by non developers?
For the first workflow, yes. For the twentieth, the skills required look a lot like programming without the tools that make programming manageable, particularly around testing and version history. Plan for that rather than being surprised by it.
How many connections justify a platform?
There is no number that fits everyone, but the shape is: few connections that rarely change favor native connectors and exports; many connections that change often favor a platform. Volatility matters more than count.
Should connections run in real time?
Only where a person is waiting. Real time costs more, fails more often, and is harder to reason about. A great deal of what gets built as immediate could be hourly, and hourly is far easier to keep working.
What happens to our connections if we change the underlying product?
They break, all of them, and rebuilding them is usually the largest hidden line in a migration estimate. Keep an inventory from the first connection so that the answer to this question is a list rather than an afternoon of discovery.
