Software integrations features worth understanding

A connection is easy to build and hard to keep. Every feature worth paying for in this part of the estate is therefore about the second year, not the first afternoon, and almost none of it appears in a demonstration, because a demonstration is a happy path.

Here is what to look for, in the order that things actually go wrong.

What to take away

What happens when one record fails

This is the first question and it splits the field.

The weak behavior is that a run reports a count of failures and moves on. The record itself is somewhere, or nowhere, and finding it means reading a log. The strong behavior is that the failed item is held, visible, with the reason attached in language a person can act on, and can be fixed and re-sent by itself.

Ask three specific things. Can I see the actual record that failed, including its contents? Can I retry just that one? And if I fix the underlying data, does the retry pick up the corrected version or the original?

Repeats, and why they matter more than they sound

Retries help systems survive unreliable networks, but they also give you two copies of everything.

A safe retry means doing the same operation twice produces the same result as doing it once. The standard description of request methods sets out which operations carry that property and which do not.

In practice, ask whether the product supports a key that identifies a record uniquely, and whether it uses that key to decide between creating and updating. A connection without one will eventually duplicate, and duplicates in a customer list or an invoice run are expensive to unpick.

Field mapping, and the guessing problem

Most of the errors in a working connection are mapping errors, and they are usually invisible for weeks.

The features that help are unglamorous: a mapping view that shows both sides with real example data rather than field names alone, and a refusal to silently truncate a value that does not fit.

Explicit handling of empty values keeps blank from quietly becoming zero. Type checking fails at build time rather than at three in the morning.

Watch particularly for dates and for anything with a decimal point. The two systems will disagree about time zones and about separators, and the disagreement will only show up on records created near midnight or above a thousand.

Schema drift

The system on the other end will change. A field gets renamed, a picklist gains a value, a required field becomes optional. Your connection was built against the old shape.

Ask what happens. A good answer: the connection fails loudly, with a message naming the field. A bad answer: it keeps running and writes nothing into the renamed field. That is data loss that reports success.

Ask whether the product can detect a schema change on its own. Ask whether it can be told to stop rather than continue.

Then ask about your side of the deal: whether you get notice before the platform itself changes anything, and where that notice is published.

Observability, meaning what you can see afterwards

You need to be able to answer, three weeks later, what happened to one specific record. That requires a log with the record in it, kept for long enough, searchable by something a person knows, such as an order number.

Ask how long the run history is kept, and whether it holds the payload or only a status. Ask whether you can export or forward it to logs you already keep.

The case for deciding retention deliberately, and keeping enough detail to reconstruct a sequence, appears in the guidance on logging and monitoring. Connection logs are among the places where the default period is shortest.

One warning. Logs in this part of the estate frequently contain real customer data, because the payload is the record. Decide who can read them before you widen access to them.

Credentials, and who owns them

A connection authenticates as something. If that something is a person, the connection has an expiry date nobody wrote down.

Look for an organization-owned identity, not an employee one. Check for platform-stored credentials, not pasted into a step. Seek rotation without rebuilding the connection. Require scoping, so a read-only connection can only read.

Scoping is the cheapest risk reduction available. It is skipped almost universally, because the fastest way to get something working is to give it everything.

Register each connection's credential with your account administration records at the point it is created, not in an audit later.

Testing, and the environment question

Ask whether there is a way to run a connection against test data without touching the live system. Many products have one, several do not, and the ones that do not force you to test in production, which people then avoid doing, which is how connections go live untested.

If no test environment exists, the fallback is a limit: run against a filtered subset, one record, and check the result by hand before widening. Slow, and better than the alternative.

Which features to weigh

Where this fits

The category overview covers how connection work accumulates. If the conclusion is that you need fewer connections rather than better ones, the simpler options are the honest read, and the selection method turns the features above into a build test. Connections into a work tracker deserve the same discipline as the tracker's own configuration, since both accumulate quietly.

Common questions

How real time does a connection need to be?

Only as real time as the person waiting for it. Immediate delivery multiplies the cost and the failure modes, and a great deal of what gets specified as instant is read at the next weekly meeting.

Should connections run under one shared account?

One account per connection is better, because it lets you scope permissions narrowly and see which connection did what in the far system's own log. One shared account for everything is convenient right up to the first investigation.

What about connections built inside the products themselves?

Same questions, fewer answers. Native connectors are usually less configurable and less observable, and that is an acceptable trade for the ones that just work. Keep them in the same register, because they fail too and nobody thinks to look at them.

How do we test something that writes to a live system?

Filter to one record you own, run it, check by hand, then widen in steps. If the platform supports a dry run that reports what it would have done, use it, and still check one record by hand afterwards.