Last post, I promised real features. Real workflows. The actual product taking shape.

So here's the first one.

The Problem: Nobody Trusts the "Activate" Button

Imagine you're a customer success manager who just built your first automation in Omumu. When a user completes Course A, automatically enroll them in Course B and tag them as "advanced."

Simple enough to describe. Terrifying to turn on.

Because what if it fires on 200 existing users? What if it sends emails to people who already completed Course B? What if the conditions are wrong and it does nothing at all?

This is the automation confidence gap. The distance between "I think this will work" and "I'm willing to bet my customer relationships on it."

Every automation tool has it. Most solve it by saying "just test it." Which means: activate it, hope nothing breaks, roll back if it does.

That's not testing. That's gambling.

What We Built: Dry-Run Mode with Virtual State

Omumu automations now have a dry-run mode. Not a "limited test" mode. Not a "sandbox environment" you have to set up separately.

You click Dry Run. The system evaluates every user against your automation's conditions. Then it shows you exactly what would happen — without doing any of it.

User A: Would be enrolled in Course B. Would receive tag "advanced."

User B: Already has the tag. Would be skipped.

User C: Hasn't completed Course A. Conditions not met.

But here's where it gets interesting. We don't just evaluate the first action and stop.

Virtual State: Simulating the Chain Reaction

Automations chain. Action 1 (add tag) might be the condition for Action 2 (send email). If you only simulate the first action, the dry run lies to you about everything downstream.

So we built virtual state tracking. When the dry run "adds a tag" to a simulated user, it remembers that. When the next condition checks "does user have this tag?" — it checks the virtual state first, then falls through to the real database.

The dry run evaluates the entire automation chain as if it had actually run, without touching a single real record.

This means a support lead building their first "onboarding complete → advanced path" automation can see the full picture before committing. How many users qualify. What each user would experience. Whether the chain of conditions and actions produces the outcome they intended.

Why This Matters for Customer Education

Remember post #319 — the feature adoption gap? 93.6% of available features go unused. The single biggest reason isn't that features are bad. It's that nobody taught customers how to use them with confidence.

Automation confidence is the same problem at the admin level. If your tool for creating educational pathways feels risky to configure, people won't configure it. They'll stick with manual processes. They'll email students individually. They'll do the thing that feels safe even when it doesn't scale.

Dry-run mode doesn't just prevent mistakes. It teaches. Every time a team member previews an automation, they're learning how the system thinks. What conditions mean. How actions chain. What "tag-based routing" looks like in practice.

The preview is the education.

The Technical Bit (For the Builders)

Virtual state is a lightweight in-memory layer that sits between condition evaluation and the database. During dry runs:

• Tag additions are tracked in a virtual tag set

• Course enrollments are tracked in a virtual enrollment list

• Email sequence subscriptions are tracked in a virtual sequence set

• Conditions check virtual state first, then fall through to real data

No database writes. No side effects. No cleanup needed. The virtual state exists only for the duration of the dry-run evaluation and is discarded afterward.

This is the kind of feature that doesn't make marketing screenshots exciting. But it's the difference between an automation tool that teams adopt and one that sits configured but never activated.

What's Next

This is the first in a series of posts showing real features as they take shape. Not mockups. Not roadmap slides. Working code, solving real problems that came up in our product-market fit research.

Next up: how we handle the gap between "course completed" and "outcome achieved" — because completion isn't competence.

This is post #322 of building Omumu in public.