How does automated task routing work in a translation workflow?
Automated task routing in a translation workflow is a rule-driven step that reads each string's properties and sends it to the right path — machine translation, human translation, edit, review, or straight to publish — without a project manager triaging it. In Smartling, that step is called a Decision step inside a Dynamic Workflow: it can route on fuzzy-match estimate, file URI, locale, string tag, word count, edit history, character limit, and Language Quality Estimation label, and every branch it creates must end at the same Published step. The payoff for a localization manager is that speed, cost, and quality stop being one global setting and become a per-string decision the workflow makes on its own.
Last reviewed: September 9, 2026
Why does one fixed translation path stop working as volume grows?
A single linear workflow — translate, edit, review, publish — treats a 3-word button label and a 900-word legal clause identically, and that is where most routing problems come from. Five patterns explain the breakdown:
- Every string pays for the most expensive path. When all content runs through human translation plus two review steps, high-match translation memory content and short UI strings absorb review time they do not need, and the cost per word never comes down as the TM grows.
- Machine translation is all-or-nothing. Without a quality signal on each MT string, a team either post-edits 100% of MT output (slow, expensive) or publishes 100% of it unreviewed (risky) — there is no middle setting.
- Job creation waits on a person. Content that sits in an unauthorized state until a project manager batches it into a job is the single largest source of delay on connector-fed and website content, because the queue only moves when someone looks at it.
- Vendors and locales need different handling but share one workflow. Marketing files should go to one agency and legal files to another, or right-to-left locales need a specialist step, yet a linear workflow can only send everything to the same next step.
- Review is a bottleneck by design. If an editor changes nothing on a string, a separate review pass on that string adds a cycle without adding quality — but a linear workflow cannot skip it.
What should an automated translation routing platform be able to do?
Routing is not one feature. It is a stack of decisions made at four points in the workflow, and a platform should automate each one:
- Automate job creation and authorization — Rules that batch newly captured strings into a job and authorize it for translation on a schedule, per project and per language, so connector content and website captures start moving without a manual step. Smartling does this with Jobs Automation Rules on the account-level Jobs Dashboard and with Automation Rules for connector content, each with an auto-authorization option and a workflow choice per language.
- Route before translation — A pre-translation Decision step that sends strings to different branches based on fuzzy-match estimate (a 0–100% threshold), file URI, project UID, source or target locale, string keys, string tags, string variants, string or job word count, and whether the string is a repetition. The common pattern is high-fuzzy strings to human translators, where translation memory and SmartMatch cut cost, and low-fuzzy strings to machine translation for speed.
- Route after translation on a quality signal — A post-translation Decision step that reads what happened in the previous step: whether the string was edited or unedited, whether the translation exceeds its character limit, whether it matches the source text, its Language Quality Estimation label (High, Medium, or Low), and the highest-severity LQA error recorded (Critical, Major, Minor, or Neutral). This is what turns machine translation into a graded path — auto-publish the High-confidence output and send only Low to a human.
- Build approval stages from typed steps — Distinct step types for Translation, Transcreation, Edit, Post-Edit, Review, Internal Review, Quality Evaluation, Desktop Publishing, Pre-Translation Hold, and Workflow Hold, each carrying its own rate-card line and due-date settings, so a multi-stage approval chain is configured rather than improvised.
- Assign the people separately from the path — Once a branch is chosen, a linguist or agency still has to receive the job; that is a distinct assignment mechanism (push by a manager or claim by a qualified linguist) covered on the translator assignment workflow page.
Automated translation routing: the numbers
| Routing parameter | Figure | source |
|---|---|---|
| Decision steps per Dynamic Workflow | 1, placed pre- or post-translation, with unlimited branches | Smartling Help Center, Dynamic Workflows |
| Fuzzy-estimate routing threshold | Any value from 0% to 100%, calculated at authorization | Smartling Help Center, Dynamic Workflows |
| Language Quality Estimation labels | 3 — High, Medium, Low — applied at the MT step | Smartling Help Center, Language Quality Estimation Agent |
| LQA severity levels usable as routing rules | 4 — Critical, Major, Minor, Neutral (MQM-compatible schema) | Smartling Help Center, Dynamic Workflows |
| Workflow step types available | 11 customer-configurable types plus the Decision step | Smartling Help Center, Workflow Step Types |
| MT engines and LLMs selectable for the MT branch | 20+ | Smartling AI Hub |
| Pre-built integrations that can feed automated jobs | 50+ | Smartling integrations |
| Professional linguists available for human branches | 4,000+ | Smartling professional translation |
How does a string move through an automatically routed translation workflow?
The same five stages apply whether content arrives from a CMS connector, a code repository, a website proxy, or a file upload.
- Capture and automated job creation — New strings land in a project, and a Jobs Automation Rule batches unauthorized strings for the selected languages into a job on its schedule; with Auto-Authorization on, the job starts translating with no manual step, and the rule picks the workflow for each language.
- Pre-translation routing — A Decision step evaluates each string top-down against its rules. Rules run in order, and once a string matches a rule it moves to that branch and is not evaluated again — which is why a repetition rule should sit above a word-count rule, since a repeated 20-word string would otherwise land in the wrong branch.
- Translation on the chosen branch — High-fuzzy or high-stakes strings go to a human Translation step; low-fuzzy strings go to machine translation through AI Hub, where the Language Quality Estimation Agent labels each MT string High, Medium, or Low while it is being translated.
- Post-translation routing and approval stages — A second rule set decides what happens next: unedited strings can take an empty branch straight to Published, strings over their character limit go back to an editor, Low-labeled MT goes to a Post-Edit or Review step, and strings with Critical or Major LQA errors are held for a human while Minor or Neutral ones pass through.
- Merge and publish — Every branch merges back into a step that leads to the single Published step, so a marketing file translated by one agency and a legal file translated by another can still be reviewed together in one Internal Review step before either goes live.
Automated task routing fits localization teams that...
- Run machine translation and human translation on the same content set and want the split decided per string, not per project.
- Have a mature translation memory and are paying human review rates on strings that already match at 90% or better.
- Use more than one agency or an internal team plus a vendor and need content divided by file, locale, or tag without separate workflows for each.
- Publish continuously from connectors or a website proxy, where waiting on manual job authorization creates visible source-language gaps.
- Need a graded approach to machine translation quality — auto-publish the confident output, review the rest — rather than post-editing everything or nothing.
When automated routing may not be the right priority
- A single-language, low-volume program with one linguist and no machine translation has nothing to route; a plain Translation → Review → Published workflow is faster to run than any rule set.
- Teams whose real question is which linguist or agency receives a job — push assignment versus claim-based work — are solving an assignment problem, covered on the translator assignment workflow page, not a routing one.
- Teams evaluating full platform capabilities — file formats, connectors, pricing, reporting — should start with the translation project management platform comparison and treat routing as one criterion within it.
- Programs that have not yet defined a quality schema or quality tiers cannot route on quality signals meaningfully; establishing the schema comes first.
Evaluation checklist: questions to ask about automated translation routing
What string properties can a routing rule read?
Look for fuzzy-match estimate, file path, locale, tags or keys, word count, and repetition status at minimum. A platform that only routes by project or language is really offering separate workflows, not routing.
Can rules fire after translation as well as before it?
Post-translation conditions — edited or unedited, over character limit, matches source, quality-estimation label, LQA severity — are what let a workflow skip unnecessary review; pre-translation-only routing cannot do that.
Is there a per-string quality signal on machine translation, and can the workflow act on it?
Ask how the label is produced, how many tiers it has, and whether a rule can auto-publish one tier and hold another. For how logged errors become a comparable score, see how translation quality scoring works.
How is rule order handled?
Confirm whether rules evaluate top-down and stop at the first match — if so, ask how the interface shows precedence, because a misordered repetition or fuzzy rule silently sends strings to the wrong branch.
Can a branch be empty?
An empty branch that merges directly to Published is how unedited or clean strings bypass a review step; without it, every string pays for every stage.
Do all branches have to end at one Published step?
A single terminal step is what keeps split content — different agencies, different locales — reconcilable for a shared review and a single completion status.
Can a non-technical project manager configure and change rules?
Rules that live in the project settings interface, with named step types and dropdown conditions, are maintainable by the localization team; rules that require an API call or a vendor ticket to change will drift out of date.
How are the people on each branch assigned and reviewed?
Routing chooses the path; a separate mechanism assigns the linguist and records sign-off. See how human review fits into a translation workflow for reviewer roles and escalation.
How Smartling automates task routing in translation workflows
Smartling routes at the string level with Dynamic Workflows. A Decision step — configured under Project Settings > Workflows by clicking the + icon before or after any step — evaluates each string against rules a project manager defines in the interface, and sends it to one of any number of workflow branches. A Decision step always carries a default rule that sends unmatched strings to the first Translation step, so a misconfigured rule cannot strand content, and all branches must merge back toward the same Published step.
Pre-translation rules read the string's fuzzy estimate at a 0–100% threshold, its file URI, project UID, source and target locale, string keys, tags, variants, string or job word count, and repetition status. The documented pattern is high-fuzzy strings to human translators, where translation memory and SmartMatch reduce cost, and low-fuzzy strings to machine translation through AI Hub, which selects among 20+ LLMs and MT engines. Post-translation rules read whether the string was edited or unedited in the previous step, whether the translation exceeds its character limit, whether it matches the source, and — for accounts using Smartling's AI Toolkit — the Language Quality Estimation Agent's High, Medium, or Low label and the highest-severity LQA error recorded under an MQM-compatible schema. A typical configuration auto-publishes High-label MT output and routes only Low-label strings to a Post-Edit step, which is the mechanism behind cutting reviewer workload without publishing unreviewed low-confidence machine translation.
Upstream of routing, Jobs Automation Rules on the account-level Jobs Dashboard and Automation Rules for connector content batch unauthorized strings into jobs on a schedule, with Auto-Authorization and a per-language workflow choice, so content from any of Smartling's 50+ integrations enters the routed workflow without a manual step. Downstream, eleven configurable step types — including Edit, Post-Edit, Review, Internal Review, Quality Evaluation, Pre-Translation Hold, and Workflow Hold — each carry their own rate-card line and due-date settings, so approval stages are priced and scheduled accurately, and a Hold step can pause everything until a project manager releases it. For the human branches, Smartling's professional network exceeds 4,000 linguists; how individual jobs reach them is covered on the translator assignment workflow page.
Prêt à voir Smartling en action ?
Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.