Use a local database on the Canvas

1. Add the connection

On the Canvas, add a new connection and choose "Local database (via agent)". Pick the paired agent and, if it has more than one, which database connection on that agent to use. There are no host, username, or password fields here — those live on the agent machine, set up during install (see Connect a database).

2. Test and browse

Use Test to confirm the platform can reach the agent and the agent can reach the database — this only checks reachability, it doesn't run anything. Browse the database's tables the same way as any other connection.

3. Pick a table and columns

Choose the table to read. List the exact columns you want — this connection type never reads every column by default, only what you explicitly pick.

4. Add a filter (optional)

A simple filter (column compared to a value, chained with AND) is supported. If a filter is too complex for direct delivery — it uses OR, NOT, or a computed condition — Publish will block with a plain message telling you to route it through a regular Nia Core workflow instead.

5. Map fields and choose the key

On the destination node's Mapping tab, map each source column to its destination field, the same mapping editor used everywhere else on the Canvas. In the Delivery section, choose the key column(s) the destination uses to match rows, and — if the mode needs one — a watermark column (a column that increases over time, used to find new or changed rows).

6. Delivery settings

• Mode — replace (resend everything each run), upsertDelta (send only new/changed rows, matched by key), or realtime.
• Watermark column — required for upsertDelta/realtime, to find what changed since the last run.
• Delete method and safety — how to treat rows missing a key value, whether an empty-source replace is allowed, and a maximum-delete-percentage guard against an accidental mass delete.
• Schedule — how often the job runs, or how often it polls in realtime mode.

7. Publish

Publish is the one action that actually sends this job to the agent — saving the Canvas graph does not. Publish shows you a diff against whatever is currently running on the agent, and clearly flags anything that forces a full reload (switching the source table, changing the key or watermark column, or switching away from upsertDelta/realtime mode) versus a change the agent can apply in place (schedule, mapping, filter value). Confirm to send it.

8. Run now, and other actions

• Run now — runs the job once immediately, optionally overriding its current parameter values for that run only; it does not change the published setup.
• Force full reload — runs once, resetting the watermark, regardless of the job's normal mode.
• Pause / Resume — stops or restarts the job's own schedule.
• Allow one large delete — a one-time confirmation when a run would exceed the configured max-delete-percentage safety guard.

9. Reading run history

Runs for a job set up this way appear both in the owning workflow's own run history and on the Agents page, showing success/failure, row counts, how long each run took, and — for a failed run — its error class.