Workflows and automations

Wrengle has one local Workflows builder for creating, dry-running, running, and scheduling a visual workflow. The Workflows tab opens that builder directly, with no secondary experience switch and no hosted workflow runner.

Choose actions by name

An Action step opens a searchable picker instead of exposing source names or raw action IDs. Enabled custom actions appear under Custom actions, trusted local plugin actions appear under Plugins, and supported first-party integrations appear under Apps. The first app action is Gmail → Create draft. Choosing an action stores its current label and description, gives a default Action step that name, and enables the matching approval-gated permission. A saved target that is later disabled or removed remains visible as unavailable so the draft is not silently retargeted.

For a Gmail draft, configure the recipient and subject in the Action step. The message body is the exact text produced by upstream workflow output rather than a separate static field. Dry run shows the resolved recipient, subject, and body together before approval. The upstream body is limited to 100,000 characters, and MIME or provider request limits can make the effective maximum smaller. Oversized complete recovery snapshots are refused safely before Gmail is contacted. Recipient and subject remain in normal local workflow settings until that workflow is edited or deleted.

Gmail is currently available through Dry run, the step-through path. The upstream AI or Fetch output shown there is simulated text rather than a live model or network result. Approving the resolved Gmail request is the one real external action: it creates the displayed draft in Gmail.

The picker also has a small Connections group. Startup can preload an already-configured Gmail token pair into the native session cache without contacting Google. Check Gmail reads non-secret native readiness; opening the picker alone performs no additional Keychain read or provider request. If attention is required, Connect Gmail starts the native desktop OAuth flow and stores tokens in the operating-system keychain. Checking or connecting Gmail does not approve a draft: each Gmail workflow action still stops at its own exact preview and approval boundary.

The lifecycle

Wrengle uses these terms consistently:

• A workflow is the editable graph and its step configuration.
• An automation is one workflow with a scheduled trigger and a pinned live workflow snapshot. It is Active when that trigger is enabled and Paused when it is disabled.
• The draft is the current auto-saved workflow definition.
• The live version is the pinned snapshot used by scheduled runs.
• Dry run is the step-through and debug path.
• Run starts an immediate unattended run of the current draft when every step is autonomous-safe.

Editing a draft does not silently change its automation. Draft changes aren't live until you choose Update live version and confirm the new pinned snapshot. Pausing an automation keeps its trigger and live version but prevents scheduled runs until you resume it.

Create a workflow

Open Workflows from any New tab (+) menu or the command palette entry Open Workflows. Wrengle opens one Workflows tab for the workspace.

Create a blank workflow or choose a starter:

• Blank workflow creates a starter Goal → AI step → Final review graph.
• Daily planning note adds a Write note step and is ready for scheduled automation after you finish its configuration.
• Web monitor adds Fetch and Write note steps and is marked Setup required. Replace the starter URL before running it. Each run summarizes the current page into a dated note; it does not compare prior runs or detect changes over time.
• Launch review is a richer workflow marked Manual recommended.

The canvas supports Goal, AI step, Fetch, Write note, Action, Terminal, Coding agent, and Final review steps. Connect steps into a reachable graph without cycles. Connections into Final review follow the current leaf steps automatically.

Workflow drafts are stored in local app settings and auto-save as you edit. They are not vault documents and are not made portable by copying only the vault folder.

Configure the steps

• Goal describes what the whole run should accomplish.
• AI step has its own role, instructions, expected outputs, model selection, and access policy.
• Fetch requires a public HTTPS URL. Wrengle applies its existing private-address, DNS-resolution, response-size, and timeout checks.
• Write note requires a safe Markdown path template under an allowed vault root such as notes/, projects/, or people/.
• Action targets a loaded configured action, trusted local plugin action, or the built-in Gmail draft action. Gmail recipient and subject are configured in the step; its body comes from upstream output.
• Terminal creates a command draft for explicit submission in Wrengle's embedded terminal.
• Coding agent records a coding-agent draft for review; orchestration does not start a new coding-agent session in this release.
• Final review synthesizes the result from the current leaf steps.

Wrengle saves incomplete drafts, but the Rust runtime validates the full graph, step configuration, access policy, unattended eligibility, and current vault binding before a workflow can become a live automation version. The editor's readiness messages come from that same runtime preflight report, so the create, publish, resume, and Run now controls use the execution rules rather than a separate browser-side checklist.

Dry-run or run the draft

Use Dry run to inspect the graph through the step-by-step debug path. Dry run keeps the existing Advance, approval, cancellation, and explicit submission controls for human-gated steps.

When Dry run reaches one or more Gmail draft actions, Wrengle freezes the exact recipient, subject, and upstream-produced body and shows that batch before approval. It durably stores the encrypted prepared effect before any Gmail request. Approval remains valid for 24 hours; rejecting, cancelling, or letting it expire makes no Gmail request. If Wrengle restarts while approval is waiting, opening the same vault can reopen that exact approval. Approval creates Gmail drafts only—Wrengle never sends them.

For restart recovery, the encrypted seven-day payload includes the complete runtime snapshot needed to reconstruct what was approved: the workflow definition and step configuration, objective, accumulated artifacts and their bodies, structured output paths, manager review and audit state, plus the exact Gmail request. The 90-day metadata/receipt layer is content-safe and uses opaque keyed request bindings; it does not retain recipient, subject, body, artifacts, or note paths in plaintext.

Use Run to execute the current draft end to end. Immediate unattended runs are limited to workflows made only from Goal, Fetch, AI step, Write note, and Final review steps. Action, Terminal, and Coding agent steps remain human-gated and make a workflow ineligible for unattended Run or automation. Manual Run, automation Run now, and scheduled executions each have a fixed 30-minute limit.

A run freezes the workflow shape it started with. A manual Run is also bound to the vault that is open when it starts; switching vaults cannot redirect its generated-note write. Within one running Wrengle app process, only one user-started foreground workflow execution per current vault is admitted across manual Run and automation Run now. If you close and reopen the Workflows view, it reconnects to either kind and resumes compact backend status checks instead of starting a duplicate. An interrupted start acknowledgement reuses its exact request for a bounded one-hour recovery window. After that window, Wrengle checks for a genuinely active run but requires a fresh user action instead of silently dispatching the old request.

Dry run separately locks workflow editing while it is waiting for approval. For an unattended run, Wrengle keeps editing locked so the run cannot change underneath itself. Stop requests cancellation of that exact unattended run. Cancellation is checked between steps and before a note mutation, but provider, fetch, or durable note work that has already started may finish. A terminal result can appear while that work finishes consistency cleanup; editing and overlapping launches remain locked until cleanup completes. For a user-started unattended run, compact backend status releases those locks as soon as it confirms cleanup is complete. Loading the full terminal detail is best effort and never extends the cleanup or editing lock; completed, failed, or stopped details can stay open for review without blocking later edits or runs.

Each step's left rail mirrors its run state: muted while inactive, your theme's live color while active, and its accent color when complete. Terminal colors remain visible while the run detail is open when the draft still matches the plan that ran, then clear when you hide it or edit the workflow. If a scheduled run used a drifted pinned version, Wrengle leaves the different current draft uncolored.

Create an automation

Choose Automate… for the selected workflow. Scheduling is daily or specific-days only. The On a schedule trigger supports:

• every day at a local time; or
• specific days of the week at a local time.

There are no cron expressions, webhook triggers, file or note triggers, meeting or calendar triggers, multiple triggers, or event payloads in this release.

Creating an automation pins the current draft as its live version and binds it to the open vault. One workflow has at most one scheduled automation. The automation panel shows whether it is Active or Paused, its recurrence and timezone, latest execution state, and whether the draft differs from the live version. From there you can run it now, edit the trigger, pause or resume it, delete it, or explicitly Update live version.

Edit trigger changes only recurrence and timezone; it never publishes draft edits. Update live version is the only control that replaces the pinned snapshot, and it asks for confirmation. Moving steps on the canvas does not count as live drift because layout does not change execution. Deleting a workflow also deletes its automation so a hidden pinned snapshot cannot keep running.

Use Manage all automations from the focused panel to review every stored trigger. The no-workflow state stays focused on one New workflow action. Older automation records whose draft is missing are labeled Workflow draft missing in the overview and can be paused or deleted there. If workflow drafts cannot load, Wrengle disables workflow editing and saving, offers Retry loading workflows, and keeps Manage automations available for recovery. The overview says Draft status unavailable instead of mislabeling those automations as orphaned.

Wrengle normally refreshes automation state immediately after local scheduler changes. If that live event bridge is unavailable, the panel and overview show a notice and check again every 15 seconds; Retry live refresh reconnects without waiting for the next poll.

Run now immediately shows an in-progress execution in the workflow UI, then retains its full terminal run detail for review during the current app session. A scheduled execution's bounded latest-execution summary appears as queued, then running, and then terminal. Wrengle persists that one content-free status summary, but not the full runtime snapshot, artifacts, or a sequence of historical runs.

The scheduler is part of the desktop app, not an operating-system daemon. It does not begin scanning or claim work until startup access preflight has settled. Wrengle and the matching vault must be open for an automation to fire or Run now. A provider or workflow secure item blocked in Limited mode prevents dependent work before a provider request or action begins. Older schedules without a vault binding remain blocked until you explicitly update their live version.

Activation, resume, and trigger edits establish a fresh cadence baseline and wait for the next matching occurrence. Creating an active automation counts as activation. The scheduler does not catch up from before activation or while paused, and an edited trigger does not replay occurrences from the earlier cadence. Catch-up is reserved for downtime: if an already-active automation misses a matching occurrence because Wrengle or its matching vault was unavailable, the most recent missed occurrence may catch up once when that app-and-vault binding is available again. Older missed occurrences are not replayed.

Admitted automations use isolated background tasks, so one slow run does not block other triggers or the scheduler's next scan. Execution uses both a finite automation admission queue and the app's bounded heavy-work capacity, shared with other heavy jobs. When heavy-work capacity is busy, an admitted automation remains Queued for up to 10 minutes. If the finite admission queue is full, additional scheduled occurrences remain due for a later scan; Run now reports that it was not started and asks you to try again. Like a manual Run, an active Run now or scheduled execution has a 30-minute limit and ends with a visible timeout failure. Work already inside a non-interruptible provider or note operation may finish afterward, and the run keeps its cleanup and overlap locks until that work drains.

Within one running Wrengle app process, Wrengle rejects a duplicate overlapping run for the same automation, including a Run now/scheduler race, rather than executing it twice. A stopped, timed-out, or otherwise terminal run keeps this guard while cleanup is still pending. This guard is process-local, not a durable cross-process lock; running multiple Wrengle processes against the same local settings is outside that overlap guarantee. Run now also reserves a currently due occurrence before execution starts so the scheduler tick in that process cannot claim that same occurrence separately. The backend revalidates the live automation before it persists that claim; if the live version changes after the start preflight, the request is rejected without writing a queued result or consuming the due occurrence.

Data, privacy, and side effects

Automation definitions and pinned live snapshots remain in local app settings. Run now and scheduled runs use the same provider and capability boundaries as an immediate workflow run.

For an AI step, the selected backend receives the workflow Goal, that step's instructions, and its upstream artifacts. A local model keeps those prompt inputs on-device. A cloud-backed model sends them to the configured provider, so do not activate a cloud-backed workflow unless that data is appropriate to share with that provider.

Fetch performs read-only HTTPS requests with Wrengle's network safety checks. Write note is constrained to allowed vault roots and Wrengle's managed output region. Within one running app process, the same automation cannot overlap with itself. Different automations can still target the same output; when they do, the last completed write owns that managed region.

Configured and plugin actions remain approval-gated. Gmail additionally persists its exact encrypted effect intent and recovery snapshot before the approval can contact Google. That prepared payload can remain encrypted in workflow.db for up to seven days; the new bridge's content-safe plaintext metadata and receipts can remain for up to 90 days. Legacy preview-authored definitions and revisions may contain plaintext names, descriptions, and action configuration and remain until explicit app-data cleanup or uninstall; they are not covered by the seven-day payload rule. Terminal commands run only after explicit submission and use your normal operating-system permissions; orchestration does not sandbox them. Coding-agent drafts do not launch a new agent session, and terminal or coding-agent output is not automatically fed into other workflow steps.

Current operational limits

• Runtime runs, full snapshots, and artifacts are not generally persisted across app restarts, so there is no general durable execution history. Wrengle persists only one bounded latest-execution summary with queued, running, or terminal status; an interrupted queued or running summary is reconciled on startup to a sanitized, content-free Interrupted outcome rather than presented as work that is still active. A Gmail approval is the narrow exception: its complete recovery snapshot and exact requests are encrypted for up to seven days, while the new bridge's content-safe metadata and receipts can remain for 90 days. Recovery discovery shows at most the newest 20 items and revokes any older waiting grants before provider contact rather than hiding actionable approval state. This is not a browsable workflow run log. If the local summary save is temporarily unavailable, later scheduler scans retry reconciliation without touching work owned by the current app process.
• Manual Run, Run now, and scheduled runs have no general automatic retry, retry/backoff policy, error workflow, user-configurable queue, or crash resume. Provider or step failures require a new explicit or scheduled launch. Gmail approval recovery reopens the same prepared action rather than restarting the workflow, and an ambiguous Gmail provider outcome is not replayed automatically. If the app is interrupted before an unattended attempt tied to a due occurrence records a terminal outcome, that occurrence can remain due for the bounded catch-up described above. Catch-up restarts the workflow from the beginning rather than resuming it, so side effects completed before the interruption may happen again.
• The scheduler scans immediately after startup access preflight and then about once every 60 seconds. A matching occurrence can therefore be claimed almost a minute after its configured time, then remain queued for up to 10 minutes if shared heavy-work capacity is busy. A queued-capacity timeout produces a sanitized, content-free capacity failure; the 30-minute manual/automation execution limit produces a sanitized, content-free Timed out failure. Neither automatically reruns the workflow.
• After workflow execution reaches a terminal result, Wrengle retries only the local terminal status-and-cadence save without rerunning workflow steps while the app remains open, and keeps that automation's process-local claim until the save succeeds and any non-interruptible cleanup drains. Interruption during that window still has the at-least-once limitation above.
• The persisted latest-run status written by the current release is a small, content-free automation summary, not a durable run log. It does not persist prompts, provider response bodies, URLs, note paths, or raw filesystem errors. Unknown error text in a recognized record stored by an older release is replaced with a generic summary before it can be displayed. The next app launch rewrites that sanitized value in the local settings file while preserving unknown or future raw records rather than destructively normalizing them.
• Pinned external-agent backends are not supported for live workflow execution in this release; use a supported local or provider-backed model for live AI steps.
• Gmail draft actions remain manual and approval-gated. They cannot run through Run, Run now, or a schedule. Jira OAuth, MCP actions, broad workflow-definition migration, and full durable run history remain deferred.
• Stop requests cancellation and waits for the backend to confirm it. Hide—called Dismiss in older builds—closes only the Workflows detail view; dismissal does not cancel backend work. If cancellation cannot yet be confirmed, Wrengle keeps the workflow locked; provider requests, fetches, or note writes that already started may still finish.
• Pausing or deleting prevents a future run that has not yet been claimed. It does not cancel work the app has already claimed: a queued or running execution can continue and produce side effects.
• Workflow data is ordered text artifacts. Typed JSON items, expressions, field mapping, conditions, loops, batching, and reusable sub-workflows are not included.
• Wrengle provides a small set of local workflow steps and configured actions; it does not offer n8n-style connector or credential breadth.

For provider boundaries, see AI and privacy. For configured actions and secret storage, see Integrations and actions. For shell behavior, see Terminal.