Connections and actions

Connect the outside services your workflows use, and choose which one an Action step reaches. Open Settings → Connections to configure external services and reusable actions.

Choosing an action

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 shows a human-readable name for every source, never the internal identifier behind it. Choosing an item also enables the matching approval-gated permission, and changing the selected source clears the old source's gate.

The picker preserves a saved action even after it 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 you 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 it creates the draft.

The opened picker includes Check Gmail under Connections. If Gmail was already configured, Wrengle loads its token pair into a private native cache at startup. Opening Workflows or the picker itself performs no additional Keychain read or provider request. Check Gmail is an explicit, non-secret readiness check.

If attention is required, Connect Gmail opens a native sign-in window and completes the connection with a local redirect and a verified code exchange. Tokens stay in the operating-system keychain and that native cache. A refresh token is required for ready status, and connecting Gmail does not require a Wrengle account. The readiness result shown here is cleared whenever Gmail connects or disconnects, and you can select Gmail ready to check again.

Being ready does not mean Wrengle acts on its own. Before Google is contacted, Wrengle 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 it never sends that draft.

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 payload contains the complete workflow state behind your approval — its configuration, objective, artifact bodies and output paths, and review history — as well as the exact Gmail request. Only the newer Gmail bridge's plaintext metadata, opaque keyed request references, and receipts are content-safe, and those can remain for up to 90 days. Editable recipient and subject values stay in your normal local workflow settings until you edit or delete that workflow. Older, preview-authored workflow definitions and revisions can contain plaintext names, descriptions, and action configuration, and they can remain until an 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 once an approved draft request reaches Gmail.

Integration availability

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 Gmail, Calendar, Jira, Linear, or webhook access, and disconnecting a provider does not sign you out of Wrengle. Gmail and Google Calendar use separate native desktop OAuth connections without requiring a Wrengle account. Jira is the exception: starting its Atlassian OAuth connection requires an active Wrengle account, then Atlassian asks you to authorize the Jira connection separately.

Jira issues from the editor

Select text in a note, open the editor Actions menu, and choose Create Jira issue. If Jira is not connected, sign in to Wrengle and connect Atlassian from that dialog, or connect first under Settings → Connections. Wrengle requests read:jira-work, write:jira-work, and offline_access: Jira-work read access populates the sites, projects, and issue types you can choose, write access creates the issue, and offline access keeps the connection usable without asking you to reconnect for every ticket.

For every ticket, choose its Jira Cloud site, project, and issue type. Review or edit the proposed summary and description before creating it. Wrengle sends those two text fields and the selected site, project, and issue-type identifiers to Atlassian. The v1 Jira action is editor-only: it is not available in the workflow builder, Run, Run now, or schedules.

Long-lived Jira OAuth tokens stay in the operating-system keychain. Wrengle's account service brokers the confidential OAuth exchange but does not become the connection store. It keeps only encrypted, short-lived records needed to complete the authorization handoff or safely replay the result of one rotating-token refresh; those records expire automatically.

Creating a Jira issue is an external side effect. If Wrengle cannot determine whether a request completed after it may have reached Atlassian, it reports Outcome unknown and does not retry automatically. Check Jira first. Only then use Resolve → I checked — clear lock so a retry cannot quietly create a duplicate issue.

Google Calendar requests only owned-event read access to the primary calendar. Google supplies event IDs, titles, and start/end times; Wrengle ignores all-day, cancelled, and non-default events. Cached rows expire after seven days. Choosing an event copies its Google event ID, source, title, and times into the frontmatter of the meeting note you own, where those fields remain until you edit or delete that note.

Calendar disconnect is deliberately local-only because Gmail and Calendar share the same Google Cloud project: Wrengle removes the Calendar tokens, scope marker, and cached Google rows without calling Google's project-wide revocation endpoint. To revoke the whole Wrengle project grant, remove Wrengle from your Google Account's third-party connections. That can also affect Gmail and requires reconnecting it. Settings keeps Remove local Calendar data available while Calendar is disconnected, so you can retry local Keychain cleanup after a denial or interrupted removal.

HubSpot remains hidden. An earlier test build's HubSpot tokens can be removed from Legacy connection data; Wrengle does not inspect them at startup.

Custom actions

The Custom actions section creates reusable Custom API/Webhook actions. They call a configured webhook or API endpoint with the method and payload shape you choose in the wizard. New Jira API-token custom actions are no longer offered; use the built-in OAuth editor action instead.

Supported custom API 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 webhook URL, and secret values are stored separately from the visible action configuration. Errors and diagnostics are expected to avoid exposing stored secrets.

Editor previews, plugin UI action dialogs, configured-action test requests, and workflow final approvals all share one slot for an external action. The active confirmation cannot be dismissed or replaced while its request is running, and another action cannot start at the same time.

Before contacting the provider, Wrengle writes a private local record that this action is in progress. That record holds only which action and which request it was — never your selected text, the request body, the provider's result, or any secret. If the app window reloads, it reattaches to that in-progress state. A process restart or reopening the same vault checks the durable record: a matching receipt recovers as Completed; an unresolved in-progress record recovers as Outcome unknown and continues to block external actions.

If a request may have left Wrengle, but sending it, reading its response, confirming success, or saving that outcome fails, the dialog closes without offering Retry. Check the external provider before deciding what to do next. Only after you have confirmed whether it completed should you use the two-step Resolve → I checked — clear lock action. Clearing the lock permits another external action, and it cannot undo a duplicate at the provider.

Every confirmation is bound to the exact vault session that captured its selection and context. Switching vaults, or reopening the same vault, closes a pending confirmation. An action that was already accepted keeps its native slot and vault lifecycle lease until the plugin finishes, its result is recorded, and that result is delivered. A vault switch waits for that to finish, so results from the prior vault are never delivered into the replacement.

Send test request is a real provider operation, not a dry run: a webhook test sends the configured request. Testing therefore requires an open vault, and it follows the same rules as a normal confirmed action — the same exact-vault slot, request tracking, durable receipt, reload recovery, and unknown-outcome handling.

Configured-action and installed-plugin secrets that are present at launch are preloaded with the other allowlisted app-owned secure items. This local check 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. Changing a secret while Wrengle is running uses non-interactive Keychain operations, so if the operating system would otherwise show a dialog, the change fails closed instead. Recovery is an explicit reconnect, or — when the current non-secret configuration still authorizes the check — a new launch.

Cleaning up legacy Jira API-token actions

Upgrading does not silently delete old Jira actions or credentials. Existing configured Jira API-token actions remain visible in Custom actions with an unsupported legacy label. An enabled one can be disabled, but legacy actions cannot be edited, tested, or re-enabled. Use Remove when you are ready; that explicitly deletes the configured action and its per-action stored secrets.

The retired built-in Jira email/API-token fields are no longer shown or used. Any old global Jira API token is left untouched during upgrade rather than being deleted without your permission. It is separate from the new OAuth connection; remove it explicitly under Settings → Connections → Legacy connection data → Remove legacy Jira token.

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, and plugin actions use approval-gated plugin access. Gmail uses its own durable, exact-preview approval instead. 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; for arbitrary scripts, 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 they cannot run unattended through Run, Run now, or schedules.
• Jira is editor-only in v1. Jira workflow actions, MCP-backed actions, broad migration into the durable workflow service, and full durable workflow history are not available in this release.