Interactive workflow steps (approve bar, DATA_TABLE inline edit/reject, FILE_UPLOAD submit) do not mutate tenant Postgres directly from the UI. The browser talks to Ntropii Tenant (Documentation Index
Fetch the complete documentation index at: https://docs.ntropii.com/llms.txt
Use this file to discover all available pages before exploring further.
api-tenant); Tenant forwards to Ntropii Workspace (api-workspace), which signals the Temporal workflow. Domain rules (ntro.subledger, activities) run inside the worker — validation belongs there, not in thin HTTP layers.
See implementation threads N-58 (architecture) and N-60 (DATA_TABLE row actions).
End-to-end sequence
Transport vs logic| Layer | Responsibility |
|---|---|
| api-tenant | Auth, tenant scope, map HTTP JSON → workspace calls. No ledger business rules. |
| api-workspace | Resolve org/task, route signal to the correct Temporal workflow execution. |
| Workflow + domain | Interpret payload, enforce transitions, call activities / ntro.subledger. |
Payload contracts (conceptual)
Step approve / reject (wait_for_action)
Used when the workflow blocks on a single HITL gate with primary actions.
| Field | Meaning |
|---|---|
type | approved or rejected — mirrors UI primary/failure CTAs. |
comments | Optional free-text (workspace may map to reason). |
POST /tasks/:taskId/action with { "type": "approved" \| "rejected", "comments": "..." }. Workspace translates into the user_action waveform your workflow expects alongside wait_for_action.
DATA_TABLE row_action (edit_cell / reject_row)
Forwarded by Workspace as a user_action whose kind is row_action (workflow drains these into on_row_action).
| Field | Required | Meaning |
|---|---|---|
ledger | Yes | Subledger name today — e.g. expenses. |
action | Yes | edit_cell or reject_row. |
rowId | Yes | Stable row UUID in the subledger table. |
field | For edit_cell | Column key (e.g. amount_gross). |
value | For edit_cell | New scalar / null — coercion and validation in workflow/domain. |
POST /tasks/:taskId/row-action with JSON matching the DTO above.
Replay, idempotency, errors
- Determinism: Workflow code must not perform non-deterministic I/O directly — mutations happen in activities or signal handlers that only record intent for activities.
- Idempotency: Row deletes/edits should be safe if the same signal is replayed or retried (workflow handlers typically gate by row status).
- Errors: Failed activities surface as workflow/activity failure or structured UI errors; inline edits show per-cell error state while approve stays disabled until conflicts resolve — driven by refreshed
UIStatefrom Tenant.
Cross-links
Workflows overview
wait_for_action, user_action, on_row_action.Subledgers
Where persisted rows live after successful signals.