Integrations and actions

Open Settings → Connections to configure external services and reusable actions.

Workflow action picker

Workflow Action steps use one searchable picker. Enabled configured actions appear under Custom actions, trusted local plugin actions appear under Plugins, and first-party integrations appear under Apps. The picker hides raw registry IDs. Choosing an item also enables the matching approval-gated permission; changing the selected source clears the old source's gate.

The picker preserves a saved action that later becomes unavailable. It labels the target unavailable and requires you to choose a replacement rather than silently pointing the step somewhere else.

Gmail drafts and readiness

Apps → Gmail → Create draft is the first built-in workflow action. Configure its recipient and subject in the Action step. The exact body comes from upstream workflow output. When Dry run reaches the action, Wrengle shows the resolved recipient, subject, and complete body before approval. The exact upstream body is limited to 100,000 characters; recipient, subject, MIME encoding, and provider request limits can make the effective maximum smaller. A full recovery snapshot that is too large is refused safely before Google is contacted.

This action currently runs through Dry run, the step-through workflow path. Its upstream AI or Fetch body is simulated; approving the exact displayed Gmail request is real and creates the draft.

The opened picker includes Check Gmail under Connections. Startup preloads an already-configured Gmail token pair into native process memory; simply opening Workflows or the picker performs no additional Keychain read or provider request. Check Gmail is an explicit, non-secret readiness check. If attention is required, Connect Gmail starts a native desktop authorization-code flow with loopback redirect and PKCE. Tokens stay in the operating-system keychain and Rust-owned session cache, a refresh token is required for ready status, and Gmail connection does not require a Wrengle account. The non-secret frontend result is invalidated when Gmail is connected or disconnected, and Gmail ready can be selected to check again.

Connection readiness does not authorize a side effect. Before Google is contacted, Wrengle durably records an encrypted intent for the exact previewed draft batch. Approval expires after 24 hours. A waiting approval can be reopened after a desktop restart when the same vault is open; rejection, cancellation, and expiry contact no provider. An approved action creates a draft in the primary connected Gmail account and never sends it.

The current picker represents one primary Gmail connection and does not offer multiple-account selection. Prepared payloads can remain encrypted for up to seven days. That encrypted recovery payload contains the complete runtime snapshot (workflow configuration, objective, artifact bodies and output paths, manager/audit state) as well as the exact Gmail request. Only the new Gmail bridge's plaintext metadata, opaque keyed request bindings, and receipts are content-safe and can remain for up to 90 days. Editable recipient and subject values remain in normal local workflow settings until you edit or delete that workflow. Legacy preview-authored workflow definitions and revisions can contain plaintext names, descriptions, and action configuration and can remain until explicit app-data cleanup or uninstall; the seven-day payload rule does not apply to those older records. Google's account, logging, retention, verification, and restricted-scope policies apply after an approved draft request reaches Gmail.

Calendar credentials created before the exact-scope policy marker existed are disconnected at the next explicit sync and require one reconnect. This avoids treating a refresh response that omits scope as proof that an older incrementally authorized token was calendar-only.

Built-in integration settings

External services receive the request data needed for the integration you run. Treat each provider's logging, retention, account, and billing behavior as separate from Wrengle's local vault storage model.

A Wrengle account is separate from a provider connection. Signing in does not grant Google, Jira, Linear, HubSpot, or webhook access, and disconnecting one of those providers does not sign you out of Wrengle. Gmail and Google Calendar continue to use their native desktop OAuth connections without requiring a Wrengle account. The account-backed Jira OAuth broker remains internal and is not an executable workflow connection in this release.

Startup loads both configured Google Calendar token items into the sealed native session cache but does not start Calendar sync, contact Google, or refresh OAuth. On macOS, the access and refresh tokens are separate Keychain items and each can therefore have its own startup dialog. Opening Meetings or choosing Refresh uses the cached access token; an expired or unauthorized response uses the already-cached refresh token, so no feature-time Keychain prompt is needed.

Choosing Disconnect publishes both Google token records as unavailable, evicts them from the native session cache, and cancels their in-flight request authority before waiting for an active Calendar sync to release its lock. That sync cannot refresh or replace the pair after revocation begins. Wrengle then purges the Google event cache and attempts both Keychain deletions without authentication UI. If the operating system would need to prompt, cleanup is recorded as pending, the connection remains revoked for the session, and ordinary Calendar work fails closed until you explicitly retry Disconnect or reconnect. Startup does not reread the old token pair behind the fail-closed broker tombstone.

Custom actions

The Custom actions section creates reusable actions from safe templates:

• Jira ticket actions use a Jira site, email, API token, and project key.
• Custom API/Webhook actions call a configured webhook/API endpoint with the method and payload shape you choose in the wizard.

Custom actions can be edited, enabled, disabled, or deleted. Enabled configured actions join the same local action registry as built-in actions and trusted plugin actions, so they can appear in editor action surfaces and workflow action targets.

Configured actions do not grant arbitrary network access. Their host capability is derived from the configured Jira site or webhook URL, and secret values are stored separately from the visible action configuration. Errors and diagnostics are expected to avoid exposing stored secrets.

Configured-action and installed-plugin secrets that are present at launch are preloaded with the other allowlisted app-owned secure items. This local preflight does not run an action, contact its host, or grant its approval-gated access. A cleanly missing secret leaves only the dependent action or plugin disconnected. A denied or locked configured secret makes that surface unavailable in Limited mode. Runtime secret changes use non-interactive Keychain operations and fail closed with an explicit reconnect, or a new launch when the current non-secret configuration still authorizes preflight, if the operating system would show a dialog.

Workflow use

Workflow Action nodes can target loaded configured actions, trusted local plugin actions, or Gmail → Create draft by name. Configured actions use approval-gated integration access, plugin actions use approval-gated plugin access, and Gmail uses its durable exact-preview approval. Running Dry run drafts the action first; final approval is the provider boundary.

Current limits

• Integrations are local app settings, not a hosted sync workspace.
• Signing in does not sync integration settings or provider credentials.
• OAuth account connections depend on the selected provider being reachable and authorized.
• Custom actions are template-based; arbitrary scripts should use the Terminal or an external agent instead.
• Provider-backed actions can send selected note text, workflow context, or configured payload data to the external service you chose.
• Gmail workflow actions create drafts only. They never send messages and cannot run unattended through Run, Run now, or schedules.
• Jira OAuth, MCP-backed actions, broad migration into the durable workflow service, and full durable workflow history are not available in this release.