Workflow completed is not the same as outcome achieved

Base URL: https://outcomeos.cloud. Competitor quotes checked 2026-11-10 on the linked pages.

Every automation tool has a run history. Every run history has a status column. And almost every status column says some version of "Success".

That word is doing a lot of work. It usually means: every step in the workflow ran, and none of them returned an error. It does not mean the thing you built the workflow for actually happened.

This post is about that gap, and why OutcomeOS is built around closing it.

Two facts that look like one

Take the most common automation a small business builds. A lead fills in a form. A workflow looks the lead up in the CRM, sends them an SMS, and pings the sales owner.

When that run goes green, you know three things happened:

1. Your workflow received the trigger.
2. The SMS provider accepted an API call.
3. The notification was posted.

What you don't know:

• Whether the SMS reached a phone.
• Whether the lead read it.
• Whether the lead replied.
• Whether anyone on your team replied back within the 5 minutes you promised yourself.

The first list is about the workflow. The second list is about the business. The business list is the one you care about. It's also the one no run history can show, because those events happen after the workflow ends, in someone else's system.

Why tools measure the workflow

This isn't a flaw in any one product. It's what workflow tools are for, and their pricing tells you so.

Zapier counts a task "whenever Zapier successfully completes a unit of work for you" (zapier.com/pricing). n8n's pricing page says you "only pay when a workflow runs from start to finish" (n8n.io/pricing). Make bills credits for module actions. Activepieces bills one credit per run.

Those are honest meters. Running steps is their cost, so it's their unit. And they are good at it: they have retries, replay, error workflows and logs. The point isn't that they do the workflow badly. It's that a workflow tool's natural definition of success is "the workflow finished".

If you want a different definition, you build it yourself. Usually that means a spreadsheet, a second workflow that polls the CRM, or someone checking by hand on Friday.

What "achieved" should mean

In OutcomeOS, an outcome is a first-class object, separate from the workflows that serve it. It has:

• A name and a description: "Every qualified lead gets a reply within 5 minutes."
• Explicit success criteria: which event, from which source, linked to which record, within what time.
• A status of its own: not started, in progress, achieved, at risk, failed, cancelled.

Workflows contribute to an outcome. They don't decide it.

The rule that makes this work is simple: an outcome is marked achieved only from a verified event. In v1, verified means one of three things:

1. A signed webhook. The sender signs the payload, and OutcomeOS checks the signature before it trusts the event.
2. An authenticated API call. A request to the OutcomeOS API with a valid key. Keys are hashed at rest.
3. A provider-signed event. An event from a provider that signs its own payloads.

Anything else is recorded and ignored for success. If a form posts {"paid": true} with no signature, you'll see it in the event log. It won't move the outcome.

And the most important negative rule: a workflow completing never marks an outcome achieved. Not even the workflow that was built specifically for that outcome.

What this looks like in practice

Here's the lead workflow again, built for an outcome.

1. Webhook trigger. The lead arrives. Duplicate triggers are dropped, so a form that fires twice doesn't start two runs.
2. HTTP request. Look up the lead. Credentials for that call are stored AES-GCM encrypted and masked in the step log.
3. Connector action. Send the SMS (Twilio, in beta with your own credentials).
4. Wait for event, with a timeout. The run pauses until a reply event arrives or 24 hours pass. Each execution has its own Durable Object on Cloudflare, so the wait is stored state, not a request held open.
5. If/else. Reply arrived? Notify the owner. Timed out? Notify the owner and flag it.
6. Emit outcome event. The workflow can report what it saw.

Step 6 is the subtle one. A workflow can emit an outcome event, but that event only counts if it comes through a verified path and meets the criteria. The workflow saying "I think we're done" isn't proof.

So on the outcome page you can end up with this, which is the honest picture: the workflow completed for 100 leads, and the outcome is achieved for the ones where a verified reply arrived. The rest are visible as in progress or failed, each with a reason.

Why the separation matters

It stops false confidence. A dashboard full of green runs feels like work getting done. If the SMS provider is accepting messages but they aren't delivering, every run is green and every outcome is stuck. You want the second number to fall so you notice.

It survives refactoring. You can rebuild the workflow, split it in two, or add a second channel. The outcome and its criteria stay the same. You compare before and after on the thing that matters.

It makes metrics traceable. Every "achieved" links back to a specific event, its source, and whether it was verified. When someone asks "how do we know 42 leads replied?", you can answer with records, not a counter.

It's harder to fool. Requiring a signature or an authenticated call means a misconfigured form, a test payload, or a replayed request can't inflate the number.

What it doesn't do

Some honest limits for v1:

• The verification is only as good as the event source. If your provider doesn't sign webhooks, you need to route its events through something that can make an authenticated call.
• Integrations are few. Signed webhooks and generic HTTP are available. Twilio SMS, HubSpot contacts and a Stripe account check are in beta. Gmail, Slack, Salesforce, WhatsApp Cloud API and others are coming. If you need a long tail of apps today, a tool like Zapier (9,000+ apps on its homepage) will connect more of them.
• OutcomeOS doesn't guarantee an outcome. It tells you, with evidence, whether it happened.

The short version

A workflow is an implementation detail. The outcome is the product.

Measure the workflow so you can fix it. Measure the outcome so you know whether to bother.

If you want to try it, Starter is free and the code is MIT: sign up, or read how we compare, including the rows where we lose. The companion post covers the other half of reliability: why we don't blindly retry non-idempotent actions.