Pipelines let you automate what happens in your account when specific events occur — for example, automatically skipping a review step when no manual edits were made, or notifying a Slack channel when a project is delivered. Instead of relying on someone to remember a manual step, a Pipeline reacts to the event itself and runs the action for you.

This guide covers everything from your first Pipeline through to Pipeline Secrets, including secrets that renew their own credentials automatically.

A Pipeline connects a trigger (something that happens in wxrks, like a work unit — an individual file or content chunk inside a project — changing status) to one or more actions (things wxrks should do in response, like updating a workflow or sending an HTTP request). You define both the trigger and the actions in a small YAML (YAML Ain't Markup Language — a plain-text, indentation-based configuration format) block, and wxrks runs it automatically every time the trigger occurs.

With Pipelines you can, for example:

ℹ️ Note: Pipelines are a separate feature from Sous Chef Agents. Sous Chef Agents control how AI shapes the tone and style of a translation, while Pipelines automate workflow and process events — status changes, task routing, notifications. They don't depend on each other, but nothing stops a Pipeline from triggering on an event related to an AI-assisted project if you need that. See Sous Chef Agents if you're looking for that feature instead.

Go to Settings > Automation Settings > Pipelines. This area has two tabs:

Click Create Pipeline on the Pipelines tab. You'll be asked for:

Save it, and it's immediately Active — wxrks starts listening for the trigger event and will run the Pipeline the next time it happens in your account. You can toggle a Pipeline Active/Inactive at any time from the Pipelines table without deleting it.

Every Pipeline's YAML has the same three parts.

This is the event that starts the Pipeline. Common triggers include a work unit's status changing, a task's status changing, a new project being created, a project's status changing, or a new user or Org Unit being added to your account. A Pipeline can also list more than one trigger — it runs whenever any of them occurs.

Each item under run is one step, identified by an action type. wxrks currently supports:

Actions run in the order they're listed, and each one can read the results of an earlier action in the same run — for example, a bw_update_workflow step deciding what to do based on whether an earlier bw_check_manual_edits step found manual edits.

Any step can include a condition — a simple true/false check that decides whether that step actually runs. For example, a condition can check the event's details (event.details.new_status == 'DELIVERED') or an earlier step's result (!job1.has_manual_edits).

ℹ️ Note: If a condition refers to a value that isn't available yet, wxrks treats it as false and simply skips that step — it doesn't stop the rest of the Pipeline.

Workflow steps referenced in a Pipeline (both as triggers and inside actions) use the same workflow UUIDs (Universally Unique Identifiers — the long code that identifies each workflow) shown in Translation Settings > Workflows — see Managing Your Custom Workflows if you need to find or set those up first.

This is a common use case: if a segment (a single translatable sentence or unit of text) in your Review step was never manually edited, there's nothing new for a linguist to check in Review 2 — so skip it automatically.

Swap reviewWorkflowUUID and review2WorkflowUUID for the real workflow UUIDs from Translation Settings > Workflows.

💡 Tip: Add a bw_debug_action step while you're testing to confirm the values you expect (like job1.has_manual_edits) are actually there.

Click the history icon next to any Pipeline to open its Executions view. Each run of the Pipeline is listed with a status (Running, Success, or Failed) and a timestamp — click View Details on any run to see the step-by-step log messages, including the exact error if a step failed.

ℹ️ Note: If a Pipeline's YAML has a syntax error at the moment it tries to run, wxrks automatically switches it to Inactive and records the parser error in its Executions log, rather than repeatedly failing on every matching event. If a Pipeline you expected to run has quietly gone inactive, check its Executions log first — it usually explains why.

Secrets store sensitive values — API keys, tokens, passwords — that a Pipeline's http or slack action needs, without putting that value in plain text inside the YAML. Create one from the Secrets tab, then reference it in your Pipeline as ${{ secrets.YOUR_SECRET_NAME }}.

Secrets are encrypted and account-scoped — only Pipelines in the same account can use them.

⚠️ Warning: Once saved, a secret's value can't be viewed again, only replaced or deleted. Keep a record of what you stored somewhere safe if you'll need it again outside wxrks.

A secret can work in one of two ways, shown in the Type column of the secrets table:

ℹ️ Note: Existing Static secrets are unaffected by auto-refresh and continue to work exactly as before. Auto-refresh is opt-in per secret.

Use this when a Pipeline calls an external service with a short-lived token, so it never fails because the stored credential went stale.

The secrets table lists every existing secret with a Type column showing either a Static or Refreshable badge, so you can tell at a glance which secrets are self-renewing.

ℹ️ Note: For a new refreshable secret, the Secret Value field can hold a placeholder or an initial token — the first refresh overwrites it automatically. wxrks never displays a saved secret value again, whether static or refreshable: reopening any secret to edit it always shows the Secret Value field empty, and you must re-enter a value to save changes. The Secret Name itself can't be changed once created, since Pipelines reference it by name.

Fill in how wxrks should call the external authentication endpoint:

For example, a provider expecting a JSON body with the client credentials would use:

⚠️ Warning: The Client Secret field is write-only: once saved, it is never returned by the API or shown in the form again. When editing a refreshable secret, leave it blank to keep the previously saved value — it is only overwritten if you type a new one.

The provider's response can return the token in the response body or in a response header.

💡 Tip: If the provider's token lifetime is short or unpredictable, raise the Expiry Buffer so Pipelines never pick up a token that expires seconds after being fetched.

⚠️ Warning: If a refresh attempt fails, the status switches to Failing and Account Admins are notified by email the first time it happens. Repeated failures on an already-Failing secret do not send another email, so don't assume silence means it recovered — reopen the secret to check its current status and the recorded error message.

Reference the secret exactly as you would a static one, with no changes needed to the Pipeline definition itself:

Every action type that reads secrets (http calls, slack messages, and others) resolves refreshable secrets automatically — there's nothing extra to configure on the Pipeline side.