The promise of workflow automation has always been that you describe what you want, the tool does it, and you stop doing it manually. The problem is the "describe what you want" step. Most recurring work is not as documented as people believe it is. It lives in someone's muscle memory, in a series of browser tabs, in a Slack thread from eight months ago that no one can find. When you sit down to build an automation for that work, you discover that describing it takes longer than the work itself.
That is the gap Sauna Labs is built to close. Instead of requiring you to describe a workflow before automating it, we watch how the workflow runs, extract the pattern from what we observe, and hand you a playbook draft. You review it, adjust the parts that are wrong, and run it. This article walks through how that process actually works, from the observation layer through to a playbook that runs on demand.
Phase one: observation and pattern detection
When you connect your tools to Sauna Labs, the observation layer starts capturing sequences. Sequences are not screen recordings or keystroke logs. They are structured event streams: an action in Tool A followed by an action in Tool B within a time window, under conditions that repeat across multiple instances.
The observation layer is looking for repetition. A single instance of a five-step sequence is noise. The same five-step sequence performed by the same person three times in a month, starting from the same trigger condition, is a pattern. The system is specifically looking for sequences that have these characteristics: a consistent starting condition, a consistent set of tools touched in a consistent order, and a consistent output state. Variation within those parameters (different record IDs, different email recipients, different task titles) is expected and does not break the pattern match. Structural variation, where the steps themselves differ, lowers the pattern confidence score.
During early observation, you will not see much in the interface. The system is in accumulation mode. You need enough instances of a pattern for the detection to reach a confidence threshold before it surfaced to you. For most workflow types, that is between three and six instances. For workflows that run daily, you see suggestions within the first two weeks. For workflows that run monthly, it takes longer. We show you a live count of detected pattern candidates in the Observations dashboard so you know what is building up, even if it has not reached threshold yet.
Phase two: the playbook draft
When a pattern crosses the confidence threshold, Sauna Labs generates a playbook draft and surfaces it for your review. The draft is a structured representation of the pattern: the trigger condition, the steps in order, the tools involved in each step, and the field mappings for any data that passes between steps.
The draft is explicit about what it is uncertain about. If the same step was sometimes performed with slightly different field values and the system cannot determine which variation was correct, it marks that step with a review flag. If a step appeared in some instances but not others, it is listed as optional with a note on the conditions under which it appeared. The draft does not quietly choose a version and present it as settled; it shows you what it observed and asks you to confirm or correct.
Here is what a typical draft looks like for a sales handoff playbook. The trigger is a Salesforce opportunity moving to stage "Contract Sent." The steps are: look up the assigned Account Executive in Salesforce, create a Notion page using a handoff template, populate the page with opportunity name, deal value, close date, and rep contact from Salesforce, post a message to the #revenue-team Slack channel with a link to the Notion page, and create a follow-up task in Salesforce for the Account Executive due in three business days. The field mappings show exactly which Salesforce fields map to which Notion template variables.
That draft took roughly two weeks of observation to generate from a team that runs this handoff four or five times per month. Before Sauna Labs, the handoff documentation was in a Notion template that was sometimes used and sometimes not, and the Slack notification was a habit not a requirement. The playbook draft made the actual process visible for the first time.
Phase three: review and refinement
The review step is where you correct the draft and add what the observation layer could not infer. The system can see what tools were touched and in what order. It cannot see why a step was sometimes skipped, or what the rep was thinking when they chose one template over another. That context comes from you.
The most common edits during review fall into three categories. First, disambiguation: the system observed two variations of a step and you pick which one is canonical, or you create a conditional branch so that both are valid based on a field value. Second, scope correction: the system included a step that was incidental (the rep happened to also check something in another tool during the same work session) and you remove it. Third, enrichment: you add a step that the observation layer could not capture because it happens in a tool that is not yet connected, or it is a human decision point where you want to add an approval gate before the automation continues.
Approval gates are worth addressing specifically. Not every step in a workflow should run automatically. A playbook that sends a contract to a customer is a playbook that should have a human review step before that action fires. You can insert a gate at any point in the playbook: the workflow pauses, notifies a specific person or role, and waits for their approval before continuing. This is not a limitation; it is a design choice. Automation that removes judgment from high-stakes steps is a design mistake. A gate keeps the automation intact while preserving the decision point.
Phase four: staging and first run
Before a playbook runs against real data, it runs in staging mode. Staging mode executes all the logic, evaluates all the field mappings, and checks that all the tool connections are functioning, but it does not commit the writes. Instead of creating a Notion page, it shows you what the Notion page would contain. Instead of sending the Slack message, it shows you what the message would say. You can inspect every output before anything goes live.
Staging mode also runs against your most recent real trigger event, which means you are not evaluating the playbook against hypothetical data. If your last sales handoff involved an enterprise deal with an unusual configuration, that is what the staging run uses. This is deliberate. Edge cases surface in staging, not in production.
Once staging looks correct, you activate the playbook. The first production run is still monitored closely. Sauna Labs logs every step, flags any output that differs from the staging preview, and surfaces the execution record for manual review. After a few clean runs, the playbook moves to standard monitoring mode, where you only see it when something goes wrong or when you go looking.
What observation cannot replace
We should be direct about what the observation-to-playbook process does not handle well. It works on workflows that already happen consistently. If your team's process for a given task is chaotic, highly variable, or spread across people who each do it differently, the observation layer will accumulate noise without surfacing a pattern, or it will surface a pattern that only reflects one person's approach. In those cases, the playbook draft is less useful as an automation starting point and more useful as a diagnostic: it will show you exactly how inconsistently the workflow is actually run, which is information worth having even if the automation is not yet ready.
The observation layer also cannot capture workflows that happen primarily in tools that are not connected. If the most important steps in a workflow happen in a tool you have not connected, those steps are invisible to the pattern detection. You can still build the playbook manually in those cases, but it starts from a blank canvas rather than an observed draft.
Playbooks are most valuable for recurring coordination work with clearly defined entry points and deterministic steps. The more a workflow relies on in-the-moment judgment calls distributed throughout the execution, the less a playbook can help with the execution itself, though it can still help with the assembly steps that feed into those judgment calls.