The first question most teams ask when they sign up for Sauna Labs is: which tools do I connect first? The second question, usually asked a few minutes later, is: and then what happens?
This article is the practical answer to both. We will walk through the first 30 minutes of setup, explain what the observation layer is capturing once you connect your tools, and give you a realistic picture of when you will see your first playbook suggestion. We will also be direct about where patience is required, because the observation model takes time that most automation tools do not.
Before you connect anything: identify a candidate workflow
The observation layer is most effective when you have a specific workflow in mind. You do not need to fully document it, but you should be able to describe it loosely: "every time we close a deal in Salesforce, our ops manager updates a Notion tracker, sends a Slack message to the revenue channel, and creates a task for the account team." That description tells you which tools are involved and gives the pattern detection something to look for.
If you connect your tools without a candidate workflow in mind, the observation layer will still accumulate data, but it will accumulate data across everything your team does. The signal-to-noise ratio is lower. You may still see useful pattern suggestions, but they will take longer to surface and may reflect workflows you were not planning to automate.
We recommend starting with one candidate workflow. Pick the one that your team runs most frequently. Frequency is the main driver of how quickly you will see a pattern suggestion. A workflow that runs five times per week will generate enough observation data in two to three weeks. A workflow that runs once per month will take longer, sometimes two to three months before the pattern detection has enough instances to reach confidence.
Which tools to connect first
Connect the tools that appear in your candidate workflow. If your candidate workflow involves Salesforce, Notion, and Slack, connect those three. You do not need to connect every tool your team uses on day one. The more tools you connect, the more data the observation layer accumulates, which is useful eventually, but it also means more setup time and more noise in the early period.
Connectors are authorized via OAuth. Go to Settings, then Connectors, and you will see the full list of supported tools. Click the tool, click Authorize, and follow the OAuth flow in the popup window. The whole process takes about 90 seconds per tool. You do not need to configure anything further to start observing. The connector begins capturing event sequences immediately after authorization.
A few connector-specific notes worth knowing upfront. For Salesforce: we will ask you to select which object types to observe. Start with the objects your candidate workflow touches, typically Opportunity and Task for revenue workflows, or Account and Contact for customer success workflows. You can expand this later. For Gmail: the default scope is metadata-only, meaning we capture that emails were sent and received but not the content. If your candidate workflow requires reading email content as a trigger condition, you will need to enable the extended scope in connector settings, which prompts a re-authorization. For Notion: we connect at the workspace level, but observation is scoped to the databases you select. If your team has a Notion workspace with dozens of databases, select only the ones your candidate workflow touches.
What happens in the first week
After you connect your tools, the observation layer starts capturing event sequences in the background. You will not see much in the interface during the first week if your candidate workflow has not run enough times yet. This is expected.
What you will see in the Observations dashboard is a live feed of the event sequences that have been captured, organized by tool. You can browse these to get a sense of what the system is seeing. You will also see the Patterns panel, which lists candidate patterns that are building up but have not yet reached the confidence threshold. Early in the observation period, you may see fragments: "Salesforce opportunity update followed by Notion page creation" with a count of 1 or 2 instances. These are the building blocks. They accumulate as more instances are observed.
The first week is also a good time to set up your data map. The data map tells Sauna Labs which fields in your connected tools contain sensitive information that should not be logged in workflow execution records. Even if you do not activate any automated workflows for weeks, getting the data map right early means you never need to worry about it when you do activate. Go to Settings, then Data Map, and review the auto-detected fields for each connected tool. Fields that the system flagged as potentially sensitive are highlighted for your review. Confirm the classification or update it.
Your first playbook suggestion
When a pattern reaches the confidence threshold, you will receive an email notification and an in-app alert. The alert will tell you the name of the pattern, the tools it involves, the number of observed instances, and a confidence score. Click through to review the playbook draft.
The draft shows the full sequence of steps with the field mappings the system inferred. Spend time reading through it carefully. The most important question to ask is: does this match how the workflow actually runs, or does it match a simplified version of how the workflow runs? The draft is generated from observations, so it reflects what the system saw. If your team runs the workflow slightly differently depending on context, the draft may reflect only the most common path.
You can edit any step in the draft. You can add steps the system did not observe (because they happened in a tool that is not connected, or because they are verbal and not captured in any tool). You can remove steps that were incidental. You can add conditional branches so that the workflow takes different paths based on field values. And you can add approval gates at any point where you want a human to review before the automation continues.
Do not rush through the review. Teams that spend 20 minutes reviewing the draft carefully tend to have much cleaner first runs than teams that accept the draft and then discover the issues in production. The draft is a starting point, not a finished product.
Running your first automated playbook
After you finish the review and save your edits, the playbook will have a status of Ready for staging. Run the staging test before activating. The staging run executes all the logic without committing any writes. It will show you exactly what would have been created, updated, or sent. It uses your most recent real trigger event as the test case, so you are evaluating the playbook against actual data rather than synthetic data.
Review the staging output carefully. Check that the Notion page content looks right. Check that the Salesforce field updates are going to the correct records. Check that the Slack message format is what you want. If anything looks wrong, go back to the draft and fix it. Run staging again. Repeat until the staging output is clean.
When you activate the playbook, it moves to Active status and will run automatically the next time the trigger condition is met. You will see a run appear in the Execution History panel. The first few runs are worth monitoring manually. Open the execution records and verify the outputs. The system also surfaces an alert if any step in a run produces an unexpected result, so you do not need to actively watch, but reviewing the first few runs yourself builds confidence that the playbook is behaving correctly.
A note on what this period actually looks like
We want to be honest that the observation-to-playbook flow is not instant. If your candidate workflow runs frequently, you can go from first connection to first activated playbook in two to three weeks. If the workflow runs less frequently, it will take longer. We have seen teams get frustrated during the observation window because nothing visible is happening in the interface, and then get surprised when three or four playbook suggestions surface in the same week once enough instances have accumulated.
The waiting is not wasted time. The observation period gives you a real picture of how your workflow actually runs, not how you think it runs. Several teams have told us that seeing their workflow pattern in the draft for the first time revealed variations they did not know existed. One team discovered that two people on the same team were running the same workflow in subtly different sequences, and the divergence was causing downstream inconsistencies in their Salesforce data. The draft made that visible. They standardized on one version before automating, which was more valuable than the automation itself.
Start with one workflow, connect the tools it touches, and let the observation layer do its work. The pattern detection is what makes the playbook useful. Rushing past it means building automation on assumptions rather than observations.