A workflow step is one stage a file passes through on its way to delivery — translating it, reviewing it, running it through DTP, and so on. wxrks ships every account with a starting set of common steps, but the step catalog itself, what each one is called, and the order they run in are entirely up to each account to define. There's no fixed platform-wide pipeline underneath.
💡 Who is this for? This guide is for Account Admins and Project Managers who need to understand how workflow steps work before customizing them within the wxrks platform.
What is a workflow step?
Every file selected for translation moves through one or more workflow steps, in sequence. Each step falls into one of two kinds, based on a single setting an admin controls per step — whether it's Editor Enabled:
Editor-enabled steps open inside the wxrks Editor. Translation and every kind of review step are the common example — a linguist or reviewer works directly on segments there.
Non-editor steps represent work that happens outside wxrks — DTP, voiceover, a sworn translation, and similar specialist work. The Project Manager downloads the latest file from the last completed step, shares it with whoever does that work, and uploads the result when it's done.
That's the only structural distinction wxrks itself enforces. Everything else about a step — its name, whether it exists at all, and where it falls in the sequence — is configuration, not platform behavior.
Workflows are fully customizable — this isn't a fixed pipeline
This is the most important thing to understand about wxrks workflows: there is no hardcoded list of steps or enforced order that applies across every account. An Account Admin can, for their own account:
Create a new step from scratch with any name — a Legal Review step, a Client Sign-off step, anything your process actually needs, not just a variant of what wxrks ships by default.
Rename any existing step's display name at any time — the name your team sees in projects and selectors is fully editable.
Reorder the entire sequence by dragging steps into whatever order matches your process — nothing forces Translation first or Review before DTP except your own account's chosen order.
Archive a step your account no longer uses, without breaking historical projects that already reference it.
The one exception is a step's internal Code (an uppercase, API-facing identifier like LEGAL_REVIEW) — it's fixed once the step is created, purely so integrations and historical data keep working, but it has no bearing on the display name or where the step sits in your sequence.
Every account can end up with a genuinely different workflow catalog and order from every other account. If your account's Home or Project screens show steps in an order that differs from what's described elsewhere in this Help Center, that's expected — it reflects your account's own configuration, not a deviation from a standard.
The full walkthrough for creating, renaming, reordering, and archiving steps — plus setting up file-extension-based recommendations and Org Unit overrides — lives in Managing Your Custom Workflows. This article stays conceptual; that one is the how-to.
The default starting point
A brand-new account starts with three seed steps — Translation, Review, and DTP — simply so there's something to work with immediately. From there, most accounts draw on a familiar library of step names as they build out their own catalog, rather than inventing every name from scratch. Commonly used names include:
Editor-enabled examples: Translation, Raw MT, Full Post Editing, Fast Post Editing, Editing, Proofreading, Review, Review 2, Review 3, Review Proofreading, LQA, In-Country Review, Regional Approval, In-Country Review 2, Web QA, Feedback Implementation.
Non-editor examples: Transcription, DTP, QA, Subtitling, Video Editing, Voiceover, Sworn, Interpretation, Development.
Treat this as a library of familiar starting points, not a fixed or exhaustive list — your account's Workflow settings may show a different set entirely, including names invented specifically for your process.
How a step behaves once it's part of a project
Regardless of what a step is named in your account, Editor-enabled steps share the same underlying behavior:
A step stays read-only until the step before it is delivered — this prevents a reviewer from working on segments the translator hasn't finished yet. On continuous projects, the next step can unlock slightly earlier, as soon as every segment in the previous step is confirmed, without waiting for a formal delivery.
A review-type step can prompt the reviewer to categorize each change they make and add a short justification — wxrks can suggest a category and explanation automatically, which the reviewer can accept or override.
A task can only be delivered once every segment in it is confirmed.
Where workflows show up
Workflows are configured at the account level and consumed at the project level:
An Account Admin defines the catalog and its order once, account-wide, in Settings > Translation Settings > Workflows — see Managing Your Custom Workflows for the full walkthrough, including Org Unit-level overrides and file-extension-based recommendations.
A Project Manager picks which of the account's steps apply to a given project when creating it — see How to create a translation project in wxrks.
Once a project exists, its steps and their progress are visible on the Project Overview page.