agenthub · workspace.read
Workspace Data
List rows from a bespoke workbench table. The batch pipeline's source when the customer's data lives in their own database.
Why the node earns its place
It resolves nothing about the target itself. It names a connection, and the gateway injects that connection's locked configuration — which database, which schema, which table. So the table is fixed by admin-registered configuration scoped to its owner, and a publisher cannot retarget it at another tenant's data by editing the canvas.
It emits the same envelope as the other sources, so the read, filter and fan-out chain works with nothing in between.
How it works at run time
- 1Name the connection; the gateway supplies the locked target and the internal token.
- 2Return rows and a count inside the standard envelope.
What comes out
output.ok did the read succeed
output.data {rows, count}
output.error {code, message} on failureWhat you wire
Inputs
Nothing to wire in.
Outputs
- okboolean
- dataobject
- errorobject
Configuration
| Key | Type | Default & options | What it does |
|---|---|---|---|
| connection * | string | — | The workspace-data list tool to read through (auth_layer tool_id, e.g. a '*_member_list' internal_service tool). The table it reads is fixed by that tool's locked config. |
What usually goes wrong
Watch for this
There is no query here — what the tool returns is what you get. Narrow with a Filter after it rather than looking for a where clause on the node.
Behaviour & provenance