When you connect Sauna Labs to your existing tools, it starts watching how your team works. That sentence is easy to say and harder to sit with. Your Salesforce instance contains deal values, contact details, and private notes that were never meant to leave the CRM. Your Gmail holds negotiations in progress. Your Notion workspace has internal docs that are sensitive by nature, not by labeling.
We hear some version of this concern from nearly every team before they connect their first tool. What exactly are you recording? Who can see it? What happens if someone runs a workflow that touches a customer's personal information? These are the right questions to ask, and this article is our attempt to answer them directly.
What the observation layer actually captures
Sauna Labs observes sequences, not content. When your account executive opens a deal in Salesforce, updates the stage, then drafts a follow-up email in Gmail, we record the sequence of those actions: which tools were touched, in what order, what fields were written to, and what the timing looked like. That sequence data is what allows us to detect a pattern and eventually suggest a playbook.
To be concrete: we capture that a Salesforce record was updated and that the "Stage" field changed. We do not capture the deal name, the account name, the dollar value, or the rep's private notes in that record. The field identifier is metadata; the field value is content. We capture the former, not the latter, unless you explicitly configure a connector to pass specific field values into a workflow trigger condition.
The same logic applies to email. We observe that an email was sent from Gmail as part of a sequence, what category of subject line it had (reply, forward, new message), and roughly when it happened. We do not index the body text, the recipient list, or any attachments unless a specific workflow action you have configured requires extracting a particular piece of structured data, like a contract value that triggers the next step.
Connector-level scoping: what each integration sees
Each connector in Sauna Labs requests a specific OAuth scope when you authorize it. That scope is the ceiling for what we can ever see from that tool. We designed the scopes conservatively on purpose.
For Salesforce, we request read access to object types and field names, and write access only to the specific objects and fields that playbook actions are configured to modify. We do not request access to reports, dashboards, or files unless a playbook explicitly uses them. If you connect Salesforce but never build a playbook that writes to the Contacts object, we have no write access to Contacts, even though the connector is active.
For Gmail, the default scope is metadata only: message IDs, timestamps, and thread structure. If you build a playbook that sends an email on your team's behalf, we request the send scope at that point, scoped to the specific workflow. We do not store email content on our servers. The message is composed in the workflow action and dispatched through the Gmail API in real time.
You can review the active scopes for each connector at any time in your workspace settings. Revoking a connector immediately removes those scopes. We receive no further data from that tool after revocation, and the OAuth token is deleted within 24 hours.
Field-level redaction for structured data
Some workflows need to read a field value in order to make a routing decision. A revenue operations workflow might check whether a deal's probability field is above a certain threshold before moving it to the next stage. In that case, the field value does cross our system boundary.
For any field value that passes through a workflow condition, we apply one of two handling modes depending on how the field was classified in your data map. Fields you classify as "sensitive" (SSN, personal email, health data, compensation, banking identifiers) are evaluated in memory during workflow execution and are never written to our logs. The condition evaluates, the workflow continues or branches, and no record of the value itself is retained. Fields you classify as "reference" (deal ID, account name, stage) are stored in the workflow execution log for up to 90 days so you can audit what happened in a given run.
The data map is something you configure during onboarding, and you can update it at any time. If you add a new field to Salesforce that contains sensitive information, you can add it to the sensitive classification before any workflow touches it.
Where workflow execution data is stored
Workflow execution logs are stored in your workspace's isolated data partition. We are multi-tenant but logically isolated: your workspace's data is stored under a workspace-specific key, and our application layer enforces that no query can cross workspace boundaries at the database level. We do not aggregate workflow data across workspaces for any purpose, including product improvement, unless you have opted into the product improvement program in your account settings, and that program includes only structural metadata (step counts, completion rates, error types), never content.
Execution logs are retained for 90 days by default. You can reduce that window to 30 days or turn off execution logging entirely in your security settings. If you turn off logging, you lose the ability to audit past runs and replay failed executions, but nothing is retained after the run completes.
We do not currently offer on-premises deployment or private cloud hosting. If your organization's security requirements include data residency constraints that prevent using US-based SaaS infrastructure, Sauna Labs is not the right fit for you yet. We are working on a data residency option for EU-based workspaces. That work is not done, and we will not announce a timeline we cannot commit to.
Access controls inside your workspace
Within your workspace, access to workflow history, playbook configurations, and connector settings is controlled by role. Workspace Admins can see everything. Members can see and run playbooks they have been granted access to, but cannot view execution logs from playbooks outside their access scope. Viewers can see playbook structures but cannot view execution history at all.
We do not build in assumptions about what your team considers sensitive. A playbook that touches your compensation data should probably be Admin-only. A playbook that sends a standard onboarding email to new accounts is fine for any Member to run. That scoping is yours to define, and we give you the role model to enforce it.
Sauna Labs employees cannot access your workspace data without an explicit, time-limited access grant from a workspace Admin. That grant is logged in your audit trail. We built it that way because we occasionally need to debug a connector issue, and we wanted a model where you could see exactly when we looked at what.
What we are still working through
We want to be honest about where the current implementation has edges. Field-level redaction relies on your data map being accurate. If a field in Salesforce contains sensitive data but you have not classified it as sensitive, we treat it as reference data. There is currently no automated scanning to flag fields that might contain PII based on their contents. That detection layer is on our roadmap but is not built yet.
We also do not yet support HIPAA-covered data. If your workflows touch protected health information in any form, Sauna Labs is not currently the right tool for those specific workflows. We can support the adjacent operational workflows in a healthcare-adjacent organization, but we have not completed a BAA program and we will not tell you otherwise.
If you have questions about a specific data type your organization handles, the right path is to email us before you connect that tool, not after. We would rather help you determine fit upfront than discover a mismatch once your team is already using the product.