Nine objects account for almost everything in KonnectHub. They are worth reading once in order, because several pairs are easy to confuse and the distinction matters later.
The tenant. Flows, deployments, triggers, connections, data stores and members all belong to
exactly one workspace, and nothing crosses between them. Your URL carries it: /w/<workspace>/….
Your source code, and its identity. A flow has a name, an author, and a history of versions. It is one of two kinds:
main.ts), deployments and triggers.lib:<name>, entered at mod.ts,
never executed on its own.A flow by itself does nothing. It has no schedule, no URL and no settings — those belong to a deployment.
Everyone in the workspace can read every flow; changing one is limited to its author, a workspace owner, and the members it has been shared with — see Who can edit a flow.
One published snapshot of a flow's source. Versions are numbered, and exactly one is the draft — the copy the browser editor and the CLI both edit.
Publishing a draft freezes it as a numbered version and bundles it in the background. A version
is only runnable once that bundle reaches READY, which is why publishing is a state to watch
rather than an instant.
A flow version plus everything needed to actually run it: which workspace, which input values, what limits, and whether it is switched on.
This is the object most of the platform hangs off, so it is worth being precise about what it owns:
| It owns | Meaning |
|---|---|
flowVersionId | The version it runs — pinned, or advanced automatically on each publish |
input | The values for the version's declared inputs |
active | Off means deliveries are held, not dropped |
concurrency | How many of its executions run at once; the rest queue |
maxRetries | Retries per failing step. Default 0 |
rateLimit | New executions per minute across all its triggers |
timeout, memoryLimit | Wall-clock seconds and MB for one run |
One flow can back several deployments — production and staging, or one per customer — each with its own inputs, its own triggers and its own history.
A deployment also has its own machine identity: the permissions it holds when its code calls back into the platform. Changing which version a deployment runs is therefore a permission-checked act, not just a settings change.
Something that makes a deployment run. There are three kinds, and they behave identically at the level that matters:
A trigger is not owned by a deployment. It belongs to the workspace, and a binding connects one trigger to one deployment. One webhook can drive four deployments; one deployment can answer to a webhook, a schedule and two event sources.
That means there are two independent switches, and confusing them is the most common misconfiguration:
| Switch | Effect |
|---|---|
The trigger's active | Off is a hard stop — the delivery is not read, not recorded, and nothing runs |
The binding's active | Off unwires this one deployment; the trigger still fires and still records |
The record of one firing. Exactly one is written every time a trigger fires — whether it reached four deployments, one, or none.
Events are the durable evidence, so statistics read off them. A webhook that received three deliveries and started no executions shows exactly that.
One run of one deployment. It holds the run's status, its steps, its logs, its result, and any events the flow emitted along the way.
An execution has a step per method your flow declared, each with its own status, result and timing. Statuses are covered in the execution lifecycle.
A service describes an outside system — its authentication method, the configuration fields a connection needs, and any event topics it publishes. Some are provided by the platform (Shopify); you can define your own.
A connection is one authenticated instance of a service: one Shopify store, one CRM account. It holds config you can see and credentials you cannot — the encrypted half never appears in an API response and is only resolved into a worker when a flow asks for it.
A table the workspace owns, with columns you define. Flows read and write it through
konnecthub/store, and rows can reference rows in another store.
Flow vs deployment. The flow is the code. The deployment is a running configuration of it. Triggers, inputs, limits and history all attach to the deployment.
Payload vs input. this.payload is what arrived with this run. this.input is the
deployment's configuration and is the same on every run.