Connector Versioning

Connector versioning is how an automation or integration platform manages releases of the prebuilt connectors its workflows run on — and whether a running workflow stays on the version it was built against or is moved to a new one. It matters because a connector is software maintained by someone who is not you, sitting between your logic and somebody else's API, and it can change under a live workflow. The result is a category of incident that is genuinely disorienting: behaviour changed and nobody on your team deployed anything. The changes are ordinary from the maintainer's side. A connector is updated to follow the underlying API, and in the process an output field is renamed or restructured, a trigger switches from polling to an event subscription, an action gains a required input, a data type is coerced differently, or an operation that was tolerant of a missing value starts rejecting it. Each is defensible maintenance. Downstream, any of them can break a mapping that referenced the old shape, or quietly change what a step returns without failing it. The questions to ask a platform are concrete. Are connectors versioned at all, and is the version visible? Can a workflow be pinned, or does an upgrade apply everywhere at once? Are you notified before an upgrade, and is there a changelog you can read rather than a release note you receive? What happens to a workflow still on a retired version — does it keep running, warn, or stop? And who maintains this particular connector: the platform, the application vendor, or a community contributor, since that determines both how fast it follows the API and how long it survives neglect. The practical habits follow from that. Record the connector version alongside the workflow that depends on it, so an incident starts with a comparison rather than a guess. Where pinning exists, pin the workflows that carry money or customer data and let the rest float. And alert on the output of a workflow — the record that should have appeared, the field that should have been populated — rather than only on whether the run reported success, because a connector change most often produces a run that succeeds with the wrong content.