Workflow History And Logs

Workflow History and Logs

Every workflow run is logged. The History view shows you what happened — when the workflow ran, what triggered it, which steps it executed, what each step output, and any errors along the way. It's the first place to look when something didn't behave the way you expected.

Where History lives

From the Workflows list, click into a workflow and pick the History tab. You'll see a list of recent runs, newest first. Each row shows:

• When the run started.
• What triggered it (event, schedule, manual, user event).
• The number of records processed.
• Per-record success and error counts.
• Total run duration.

Click any row to open the run detail view, which shows every step that fired with its inputs, outputs, and timing.

Three views: Queue, Running, History

View	What it shows
Queue	Workflow runs that are scheduled to fire but haven't started yet. Useful for confirming a schedule is set up correctly.
Running	Currently active workflow runs. For long-running flows you can see what's happening in near real-time.
History	Completed runs (success or error) and their full step-by-step logs.

Step-by-step logs

The run detail view groups logs by step. For each step you can see:

• Step name and type — easy to scan when there are many steps.
• Inputs — the resolved value of every input (after value mappings are applied).
• Output — what the step returned (record IDs, response payloads, file URLs, AI responses).
• Status — success, skipped (condition not met), or error (with the error message).
• Duration — how long the step took.
• Custom Code logs — anything you wrote with console.log appears here.

Filtering and searching

The History view supports filters so you can find what you're looking for in busy workflows:

• By date range.
• By status (success / error / skipped).
• By trigger type (event / schedule / manual).
• By step type (only show runs that hit a specific Condition step or Branch).
• By record ID — show every run that processed a specific record.

Dry Run mode

Dry Run executes the workflow end-to-end without performing real side effects:

• No emails, texts, or webhooks fire.
• No records are created, updated, or deleted.
• External integrations (Slack, Stripe, etc.) are simulated.
• Custom Code still runs — but its outputs aren't applied.

Use it to walk through a workflow with real data and confirm it would do the right thing — without actually doing it. The dry run shows up in History tagged as Dry Run so you can tell it apart from real runs.

Dry Run is the safest way to test workflows that update data, send messages, or charge cards. Always dry-run before activating a high-impact workflow.

When something errors

If a step errors, the run is marked as failed and the error message is recorded in the step's log. Subsequent steps still run by default — Tadabase doesn't halt the whole workflow on a single step failure unless the failure is at trigger or guardrail level.

Common error sources:

• Send Email / Send Text errors — usually invalid recipients, missing email field, or quota reached.
• Integration errors — re-authenticate the connector or check rate limits.
• Custom Code errors — the JS threw, timed out, or hit memory limits.
• Webhook errors — the receiving URL returned a non-2xx status.
• Guardrail errors — the workflow exceeded a safety limit (max steps, max chain depth, or max execution time).

The Action Log

Each step that affects records writes an entry to the Action Log. This is separate from the workflow History — it's a per-record audit of which workflows touched which records, useful when you're debugging "why did this field change?" The Action Log is reachable from the workflow history detail view, and most record detail views surface it as well.

Log retention

Workflow logs are kept for the period your subscription allows. Higher-tier plans retain logs longer. If you need to analyze older runs, export them or copy interesting log entries before they age out.

Real-time notifications

For client-side workflows (the ones triggered from the user's browser), the user sees status messages live as each step runs. The messages come from each step's notification settings — you can customize the start/processing/success/error text on every action step.

Troubleshooting tips

• Start with the most recent failed run. Open it, look for the first red step.
• Check the resolved inputs. Most workflow bugs are an input that resolved to something unexpected — a field that was empty when you thought it had a value.
• Re-run a single record from the History view to test a fix without waiting for a real trigger.
• Use Custom Code console.log for tricky cases — log every value, then read the log in the run detail.
• Compare two runs — open a successful run and a failing run side-by-side. The first place they diverge usually tells you the cause.