What Happens When Your Automation Platform Does Not Have a Connector?

When an automation platform does not have a connector for a system, the next step is to identify the interface that system already exposes. That may be an HTTP API, an enterprise protocol, a database interface, a command-line utility, or a file exchange. If none of those provides the exact operation required, a code node can implement the final gap inside the same governed workflow.

The practical sequence is connector first, then API or protocol, then database or enterprise interface, then Rules + Code. This avoids two bad extremes: waiting indefinitely for a connector catalogue to cover a local system, or writing the entire process from scratch because one step is unusual.

Nexus provides 1,480+ prebuilt connector actions, but breadth is not the same as completeness. Every organisation has custom applications, older interfaces and local conventions. Extensibility matters because it lets those exceptions remain part of one observable run rather than becoming an unmanaged script beside it.

A prebuilt action is usually the fastest option because authentication, request shape and result handling are already packaged. It is appropriate when the required system and operation are covered and the action exposes the controls the process needs.

A direct API or protocol is the next choice when the system exposes a stable interface but the desired operation is not represented in the catalogue. Database access can be appropriate for approved reads or writes where the system owner supports that contract. Enterprise interfaces and command execution cover systems whose integration model predates modern APIs.

Rules + Code is the escape hatch for organisation-specific logic. Nexus supports Python, Bash, Go, Java, .NET, PHP, PowerShell, and JavaScript or TypeScript through Deno. The language is chosen for the task and existing libraries, not because code is treated as a synonym for Python.

• 01Connector action for known operations
• 02Direct API or enterprise protocol
• 03Approved database or infrastructure interface
• 04Rules + Code for the remaining gap

The architectural mistake is not using code. It is letting the code become a separate operational system. A script running from a laptop or an unobserved scheduler has its own credentials, failure behaviour and log history. It becomes the seam that nobody can explain later.

Inside a Nexus workflow, the custom step receives defined inputs, returns defined outputs and uses vault-backed credentials. Retries, timeouts, branches, approval and execution history remain part of the same run as the prebuilt actions around it. The implementation changes, but the governance model does not.

That continuity is especially important when a process combines SAP, Salesforce, files and an internal service. A reviewer should not need four consoles to establish which payload was sent, which response came back and why the workflow chose its final action.

A direct interface can fail in ways a connector may normally hide: authentication expiry, schema drift, malformed responses, rejected writes or a service that becomes temporarily unavailable. Those outcomes need explicit branches before the process is relied on.

Decide which failures are safe to retry, which require correction, and which require a named person. Preserve the rejected payload and response where policy permits. If a fallback interface has different semantics from the prebuilt action it replaces, document that difference in the workflow rather than treating the two as interchangeable.

The goal is not to make every interface look identical. It is to give every interface the same operational discipline: scoped authority, predictable failure handling and an attributable result.

Connector counts are useful evidence of coverage, but they do not answer what happens on day two when the process reaches a system unique to your organisation. Ask whether direct interfaces and code execute under the same identity, secret handling, approvals and audit as the catalogue actions.

Also ask whether custom logic can be versioned with the workflow, whether an operator can inspect its input and output, and whether the platform can run it in the deployment boundary you require. An escape hatch that loses governance is not an extension model. It is a second platform hidden inside the first.

The strongest architecture is prebuilt where it exists and programmable where it does not, with no break in the execution record between those two modes.