Your workflow content should not become our product dataset.
SHVL is built to remove repetitive work, not to quietly hoard the emails, reports, and documents that pass through it. The short version: we need enough access to run the workflow, but we do not need your raw workflow content sitting in SHVL run history.
SHVL is not local-only today. It uses connected apps and cloud execution to run workflows. What we can promise is minimisation: your connected systems remain the source of truth, your data remains yours, SHVL accesses it to do the job, and run history should keep usage metadata rather than the body of your emails or reports.
For the exact browser vs cloud boundary, current telemetry, and storage behaviour, see Data handling and Cookies & storage. For the public-site accessibility standard we are working to, see Accessibility. For site-level public terms, see Terms.
What SHVL needs
To run a workflow, SHVL may need temporary access to items like inbox messages, spreadsheet ranges, or draft output. That is how the workflow does useful work.
- Connected app access is used to fetch, read, draft, label, or append data.
- Your source systems stay where the real data lives: Gmail, Sheets, Outlook, Excel, Slack, and so on.
- We keep enough configuration to make the workflow run again without redoing setup every time.
What SHVL should not keep
Workflow history should not become a second archive of your business content.
- No raw email bodies stored in run logs by default.
- No saved report output bodies in routine run history.
- No need to persist the actual request payload just to count that the workflow ran.
Matching your writing style should be opt-in.
Yes, SHVL can draft replies in a way that sounds more like you. But the safer default is explicit guidance, not silent mailbox mining.
- Best current path: you provide reply style notes or a few example replies for SHVL to mirror.
- Safer than automatically learning from everything in your sent mail.
- If deeper style learning is added later, it should be optional, transparent, and revocable.
We do want usage data, just not content.
SHVL needs product telemetry so we can see what workflows are actually valuable and what breaks in the real world. That does not require your message bodies.
- Useful telemetry: workflow started, workflow succeeded or failed, duration, steps completed, connector used.
- Useful site analytics: Ahrefs Web Analytics page views, plus selected SHVL funnel events like checkout clicks, demo requests, workflow views, and install intent.
- Not needed for product improvement: the full body of every email or generated reply.
What SHVL is moving toward.
The product is being tightened around privacy-safe execution and content-light telemetry.
- Run history should keep metadata like status, duration, app usage, and rough operational counts.
- Generated content should be shown to the user in-session or drafted directly into the connected tool.
- If a workflow truly needs persistent content storage later, that should be explicit and narrow, not the default.
Want the bottleneck removed without handing over a content archive?
Tell us the repetitive request or admin loop you want SHVL to handle first. We can shape the workflow around a privacy-safe execution path from the start.
Related pages: Data handling, Cookies & storage, Terms, and Accessibility.