Getting Started with Pipelines in wxrks
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.
💡 Who is this for? This guide is for Account Admins who need to set up event-triggered automations that update workflows, tasks, and project statuses without manual intervention within the wxrks platform.
What Are Pipelines?
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 configuration, and wxrks runs it automatically every time the trigger occurs.
With Pipelines you can, for example:
Automatically skip or advance a workflow step based on a condition, such as whether a segment was manually edited.
Change a project's status automatically when certain conditions are met.
Send a notification to Slack or call an external system over HTTP whenever something happens in a project.
Sync data — like a QuickBooks record ID — onto a User or Org Unit after an external system responds.
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.
Where to Find Pipelines
Go to Settings > Automation Settings > Pipelines. This area has two tabs:
The Pipelines tab, where you create, edit, activate/deactivate, and monitor your Pipelines.
The Secrets tab, where you store sensitive values (like API tokens) your Pipelines can reference without exposing them — see the Pipeline Secrets section below.
Only Account Admins can see and use this area — it applies to your whole account, not just one Org Unit or project.
Creating Your First Pipeline
Click Create Pipeline on the Pipelines tab. You'll be asked for:
Name — a unique, space-free identifier for the Pipeline (e.g.
skip-review-if-no-edits).Description — a short summary of what it does, so your team can tell Pipelines apart later.
Configuration (YAML) — the trigger and the actions, written in YAML (see the next section).
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.
Anatomy of a Pipeline: Triggers, Actions, and Conditions
Every Pipeline's YAML has the same three parts:
1. The trigger (on)
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.
2. The actions (run)
Each item under run is one step, identified by an action type. wxrks currently supports:
bw_update_workflow— updates the status of one or more workflows and, optionally, their tasks.bw_create_workflow— adds a workflow to project files that match specific file extensions.bw_check_manual_edits— checks whether a work unit has manual edits in specific workflows, so a later step can act on the result.bw_check_comments— checks whether comments exist on a project or on specific segments.bw_check_project_work_units— checks whether every work unit in a project has reached the Closed status.bw_change_project_status— changes a project's status (Draft, Pending, Approved, Delivered, or Cancelled).bw_update_entity— writes specific fields to a User or Org Unit record, such as a QuickBooks ID after an integration call.http— calls an external URL (for example, a webhook or a third-party API).slack— sends a message to a Slack channel.bw_debug_action— logs the Pipeline's current values, useful while you're building and testing a configuration.
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.
3. Conditions
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). 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 shown in Translation Settings > Workflows — see Managing Your Custom Workflows if you need to find or set those up first.
Example: Skip a Review Step When There Are No Manual Edits
This is a common use case: if a segment in your Review step was never manually edited, there's nothing new for a linguist to check in Review 2 — so skip it automatically.
name: skip-review-2-if-no-edits
on: [WORK_UNIT_STATUS_CHANGE]
run:
- name: check-manual-edits
action: bw_check_manual_edits
id: job1
condition: event.details.new_status == 'DELIVERED'
with:
workflows:
- reviewWorkflowUUID # Review
- name: skip-review-2
action: bw_update_workflow
id: job2
condition: event.details.new_status == 'DELIVERED' && !job1.has_manual_edits
with:
workflows: []
update_workflows:
- review2WorkflowUUID # Review 2
update_task_status: SKIPPED
update_work_unit_status: SKIPPED
update_tasks: true
same_language_workflows: true
same_file_workflows: trueSwap reviewWorkflowUUID and review2WorkflowUUID for the real workflow UUIDs from Translation Settings > Workflows. Add a bw_debug_action step while you're testing to confirm the values you expect (like job1.has_manual_edits) are actually there.
Monitoring Pipeline Runs
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.
One behavior worth knowing: 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.
Pipeline Secrets
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. Once saved, a secret's value can't be viewed again, only replaced or deleted, so keep a record of what you stored somewhere safe if you'll need it again outside wxrks.
Related Articles
Sous Chef Agents — a separate automation layer that controls AI translation tone and style, not workflow events.
Managing Your Custom Workflows — find the workflow UUIDs a Pipeline needs to reference.
How to use the Auto Task Placement feature — a built-in automation for assigning tasks to vendors, no Pipeline required.
How to use wxrks Quote Automation — automate project quoting.