Workflows

Build a workflow to automate a task, then run it once or put it on a schedule. Wrengle has one local Workflows builder for creating, dry-running, running, and scheduling a visual workflow — opened directly from the Workflows tab, with no secondary experience switch and no hosted workflow runner.

Terms

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.

Build 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 start from a template:

• 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 once you finish configuring it.
• Web monitor adds Fetch and Write note steps and is marked Setup required. Replace the starter URL before you run 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 your current leaf steps automatically.

Workflow drafts are stored in local app settings and auto-save as you edit. They are not vault documents, so copying only the vault folder does not carry them with it.

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, a trusted local plugin action, or the built-in Gmail draft action. You configure the Gmail recipient and subject in the step; its body comes from upstream output.
• Terminal creates a command draft for you to submit explicitly 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 your current leaf steps.

Wrengle saves incomplete drafts, but its own 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 preflight check, so create, publish, resume, and Run now all use the same execution rules rather than a separate checklist.

Choose an action

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 — currently 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 stays visible as unavailable, so your draft is never 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 you 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 stay in normal local workflow settings until you edit or delete that workflow.

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

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 — see The approval boundary below.

Run or dry-run your workflow

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, including a Gmail draft action.

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 allowed 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 capped one-hour recovery window. After that window, Wrengle checks for a genuinely active run but requires a fresh user action instead of silently resubmitting 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.

Schedule an automation

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.

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, and editing the trigger preserves the pinned live version — 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 capped 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.

Accepted automations run in 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 accepted 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.

The approval boundary

A Gmail draft step cannot run unattended or on a schedule. It only runs through Dry run, and only after you approve the exact request it built.

When Dry run reaches one or more Gmail draft actions, Wrengle freezes the exact recipient, subject, and upstream-produced body and shows you that batch before approval. It stores the encrypted prepared effect durably before making any Gmail request. Approval stays valid for 24 hours; rejecting, cancelling, or letting it expire makes no Gmail request at all. If Wrengle restarts while an 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 snapshot needed to reconstruct what you approved: the workflow definition and step configuration, the objective, accumulated artifacts and their bodies, structured output paths, manager review and audit state, and the exact Gmail request. The 90-day metadata and receipt layer is content-safe and uses opaque keyed request bindings; it does not retain the recipient, subject, body, artifacts, or note paths in plaintext.

Data, privacy, and side effects

Automation definitions and pinned live snapshots stay 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 resolved direct OpenAI/Anthropic model or selected Wrengle AI tier receives the workflow Goal, that step's instructions, and its upstream artifacts. On a managed tier the content transits Wrengle and OpenAI. Only turn on a workflow when that data is appropriate to share. Legacy Retired-provider steps are shown as Needs attention and cannot run, publish, or stay enabled until you choose a cloud 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 stay approval-gated. Gmail additionally persists its exact encrypted effect intent and recovery snapshot before 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. Older preview-authored definitions and revisions may contain plaintext names, descriptions, and action configuration and remain until you run an explicit app-data cleanup or uninstall — the seven-day payload rule does not cover them. Terminal commands run only after you submit them explicitly, and they 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 limits

• Wrengle does not generally persist full runtime snapshots or artifacts across app restarts, so there is no general durable execution history. It persists only one capped 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 instead of appearing as work that is still active. A Gmail approval is the narrow exception: its complete recovery snapshot and exact requests stay 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 contacting the provider, 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 need 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 that 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 or automation execution limit produces a sanitized, content-free Timed out failure. Neither one reruns the workflow automatically.
• After a workflow run reaches a terminal result, Wrengle retries only the local terminal status-and-cadence save without rerunning workflow steps while the app stays open, and it keeps that automation's process-local claim until the save succeeds and any non-interruptible cleanup drains. An interruption during that window still carries the at-least-once limitation described 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 from an older release is replaced with a generic summary before Wrengle displays it. The next app launch rewrites that sanitized value in the local settings file, while unknown or future raw records are preserved rather than normalized away.
• Pinned external-agent backends are not supported for live workflow execution in this release; use a supported direct OpenAI/Anthropic model or Wrengle AI tier for live AI steps.
• Gmail draft actions stay manual and approval-gated. They cannot run through Run, Run now, or a schedule. Jira issue creation is editor-only in v1; Jira workflow actions, MCP actions, broad workflow-definition migration, and full durable run history are not available yet.
• 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 an automation 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.