CEDX Workflow · Platform
Thirty-six workflows and 243,896 runs in the demo estate, with the parts automation tools usually hide priced on screen: retries at $165 a month, a 94.7% success rate held against a 99% SLA target, and 8 approvals waiting on a human, by design.
The most honest card on the Pulse is the smallest: approvals pending — 8, human-in-the-loop. The automation stops where a person should decide, and says so.
Runs on demo data. The demo tenant in the captures is the software's demo workspace, not a customer.
What it is
The definitions table carries runs, ok %, p95 and open failures on every row: the order-to-invoice flow has 48,200 runs at 98.4% with a 1.2s p95, next to a paused dunning pack at 88.7% and 10 seconds. Drafting starts from a sentence — the describe-an-automation bar is on the screen.
Thirty-two triggers across webhook, schedule, event, queue, record and manual — each with fires per day and lag in seconds. The order-paid webhook fires 1,240 times a day at 0.4 seconds; eighteen triggers sit over the three-second lag line, which is a count, not a vibe.
The run ledger shows cost, duration, steps and retries per row — 46 seconds and 26 cents for a nightly reconcile, with failures named: network reset, connector down, timeout. Agent runs are a kind of their own: 72 tool-call executions in view.
Product tour
Not a mockup and not a concept deck. This is what opens at /app/workflow.
01 — Pulse
Reliability attainment reads 96% of target, and the alerts carry causes: a schema mismatch fanning out to 8 workflows that share a connector class; retry cost concentrated in one dunning path; a 99% success streak on nightly inventory reconcile held up as the good example.
02 — Workflows
Thirty-six definitions with status, trigger, steps, runs, ok %, p95, open failures and owner. The paused rows are as legible as the live ones — a queue-triggered dunning pack at 88.7% is paused with its record attached, not quietly deleted.
03 — Triggers
Every trigger lists what it starts, how often it fires and how late it runs. A schedule trigger at 7.5 seconds lag and a webhook at 0.4 are different operational facts, and the table treats them that way.
04 — Runs
Run ids with workflow, status, kind, cost, duration, steps, retry count and error. The 8 approvals pending are a chip on this screen — a person is the step the automation is waiting on, and the wait is visible.
Who runs it
Roles, not references. We have no named customers yet, so nobody in these photographs is quoted, credited or claimed as one.
Owns the approval queue: 8 pending human decisions between a run and its side effects, worked from the same screen the automation waits on.
approvals · 8
Owns the trigger estate and the failure ledger — 18 triggers over the lag line and 76 open failures are theirs to work down.
open failures · 76
Owns the retry cost base: $165 over 30 days, argued per path — the dunning path alone is the line item the alert names.
retry cost · $165The shape of it
Every figure below is legible in the captures above. Nothing here is a projection of your estate — it is the state of the demo data.
How it runs
A trigger starts the run — webhook, schedule, event, queue, record or manual — with its lag already being measured.
Steps execute and the cost accrues in cents, visible on the row while the run is still warm.
Where a person should decide, the run waits: 8 approvals pending is a queue, not an error state.
Success or failure, the ledger keeps the row — 94.7% average success, retries priced at $165, failures with named causes.
One record
Workflow is how the estate moves: events in, actions out, people in the loop where the decision is theirs.
Event triggers are one of the six trigger types on the Triggers table — the streams Events runs are what they fire on.
CEDX NotifyDunning paths and alert relays end as deliveries — the campaigns and templates Notify tracks are workflow outputs here.
CEDX EntitlementsGated rollouts and dual-review freezes are flags in Entitlements; the workflows respect the same gates.
CEDX FunctionsCustom steps run as functions — the unit a workflow step becomes when the built-in actions are not enough.
Limits
Finding this out on the third call is worse for you than reading it here, and worse for us.
Start
Open it right now
Your triggers, your flows
Workflow with the rest of it
Questions
Yes. Every screenshot is a capture of the running build and you can open the same build at /app/workflow. It runs on demo data, which the page says next to the figures rather than in a footnote.
A workflow can declare an approval step, and the run waits there: 8 approvals are pending in the demo ledger, visible as a chip on the Runs screen. The automation does not improvise past a decision that belongs to a person.
Three ways, all visible: retries with a priced cost base ($165 over 30 days in the demo), error names on the failed rows (network reset, connector down, timeout), and blast radius scoring on the failures that fan out — the worst score 99 and share a connector class.
Six trigger types, each on the Triggers table: webhook, schedule, event, queue, record and manual. Fires per day and lag in seconds are measured per trigger — the busiest fires 1,240 times a day at 0.4 seconds.
The Workflows screen opens with a describe-an-automation bar — the placeholder itself gives the example, an overdue-invoice chase that waits for approval — and a Draft workflow button. What it generates still lands in the same ledger as everything else.
No certification has been issued. What we can evidence about hosting, encryption, tenant isolation and production access is written up on the security page.
Live build, demo data, no card. Then ask what last month's retries cost your own automations.