What approval workflow controls should a translation platform provide?

A content approval workflow in a translation platform is the set of configurable steps and step-level settings that decide whether a translated string can publish, who can change it, where it goes if rejected, and how long it may wait before someone is alerted. In Smartling, those controls are workflow step types (Review, Internal Review, Pre-Translation Hold, Workflow Hold), per-step settings such as "Users can revise content," "Users can reject content to another step," and "Pre-publish strings," the Idle String Rule, and two records of what happened — the String Changes Report and the CAT Tool's Translation History panel. Localization managers evaluating platforms on approval workflow should test these controls directly, because they determine cycle time and auditability more than the number of review stages does.

Last reviewed: September 10, 2026

Why do translation approval workflows stall or lose their audit trail?

Approval workflows in translation break for reasons that are structural, not personal. Five patterns account for most of the delay and most of the missing records:

  • Approvers can edit when they should only approve. When a reviewer step allows free editing, an internal approver rewrites translations instead of accepting or rejecting them, the linguist's work and the approver's work blur together, and nobody can say afterwards which version was approved.
  • Rejected strings have nowhere specific to go. If a rejection always falls back to the first translation step, a string rejected for a formatting issue re-enters the full workflow and pays for translation again, while the editor who introduced the problem never sees it.
  • Publishing is all-or-nothing. Without a holding step, a 20-language product release publishes language by language as each finishes, so the live product shows mixed states; without a pre-publish option, urgent fixes wait behind a full approval chain even when the risk is low.
  • Nothing flags a string that is sitting idle. A string that entered an approval step on Monday and is still there on Friday looks identical to one that arrived an hour ago, so delays surface only when a due date is already missed.
  • Change history lives in email or memory. When the record of who changed a translation, at which step, and by how many characters is not kept by the platform, an audit request or a quality dispute six months later has nothing to draw on.

What does a complete set of approval workflow controls include?

Treat approval as five separate controls, each configured per workflow step rather than as one global "review" toggle:

  • Gate step types — Distinct step types for approval work: in Smartling, Review (opens in Review Mode by default), Internal Review (for an organization's own team, completed in the CAT Tool), and two Hold types — Pre-Translation Hold, which pauses strings before any translation work begins so costs can be approved first, and Workflow Hold, which pauses translated strings until an Account Owner or Project Manager releases them from the Strings View, so everything can publish at once.
  • Edit and reject permissions per step — A "Users can revise content" setting that, when off, locks the translation field so approvers can only approve, raise Issues, or log LQA errors; a "Users can reject content to another step" setting that names the exact step a rejected string returns to instead of defaulting to the translation step; and "Users can reject and edit published content," which decides whether an already-published string can be reopened at all.
  • Publish trigger — A "Pre-publish strings" setting with three values: Never (publish only from the final step), On save, or On submit. Pre-publishing an unedited machine translation pushes it to the final environment without saving it to translation memory, while pre-published human translations are saved to the TM — a meaningful difference for teams that want speed on low-risk content without contaminating the TM.
  • Automatic pass-through and idle handling — TM Match Skipping moves a string past an Edit, Review, or Internal Review step automatically when its TM match meets a percentage threshold, and the Idle String Rule sends an email or moves the string to the next step after a set period in a step. The two are mutually exclusive with pre-publish on the same step, which forces an explicit choice between speed and control.
  • Change record — A per-string history of every workflow action. Smartling's String Changes Report records the action that moved each string (REVIEW, REJECT, EDIT, MOVE, CUSTOM_MOVE, SMARTMATCH, and others), the edit distance between steps and to the published version, and the fuzzy score, filterable by project, workflow step, job, language, and user; the CAT Tool's Translation History panel shows the same actions with the acting user's name at string level.

How the people in those steps are assigned, what Review Mode looks like, and how sign-off is recorded by role is covered on the human review workflow page; rule-based routing between branches is covered on the automated task routing page.

Approval workflow controls: the numbers

Contrôle Figure source
Review-type step types3 — Review, Internal Review, Transcreation ReviewSmartling Help Center, Workflow Step Types
Hold step types2 — Pre-Translation Hold, Workflow HoldSmartling Help Center, Workflow Step Types
Pre-publish trigger options3 — Never, On save, On submitSmartling Help Center, Configure Workflow Steps
Workflow action types recorded per string10, including REVIEW, REJECT, EDIT, MOVE, CUSTOM_MOVE, SMARTMATCHSmartling Help Center, String Changes Report
String Changes Report history windowPast 6 months; 500 rows on screen, full set in CSV; data refreshed every 24 hoursSmartling Help Center, String Changes Report
Fuzzy score scale in the CSV export0 to 1000 (1000 = 100% match)Smartling Help Center, String Changes Report
Content Velocity reports2 reports (by Workflow, by Locale), 4 charts each, exportable to PDF or CSV on a scheduleSmartling Help Center, Content Velocity Reports
Workflow scope optionsAccount-level (all projects, Account Owners only) or project-level (Project Managers), with a default workflow per target languageSmartling Help Center, Introduction to Workflows

How do you set up an approval workflow for a new content type?

The same five decisions apply whether the content is a marketing campaign, a legal notice, or an app release.

  1. Pick the workflow scope and template — Create the workflow at account level if the same approvers work across projects (one place to update settings and onboard reviewers), or at project level if a vendor or reviewer should see only one project. Set it as the default workflow for each target language so authorization does not depend on someone remembering to choose it.
  2. Add the gate steps — Insert an Internal Review step for the organization's own approvers, a Review step for linguist review, a Pre-Translation Hold if cost must be approved before work starts, and a Workflow Hold before Published if all languages must go live together, as with a staged app release.
  3. Set each step's approval behavior — Turn "Users can revise content" off on approve-only steps, point "Users can reject content to another step" at the step that should receive rejections (an Edit step, not the translation step, for formatting problems), and decide whether "Users can reject and edit published content" should be on at all.
  4. Choose the publish trigger and the safety valves — Leave "Pre-publish strings" at Never for regulated content; use On submit for low-risk content that needs speed. Add TM Match Skipping on Edit or Review steps where high-match content should pass through, and configure the Idle String Rule so strings that sit past a set period trigger an email or move forward automatically.
  5. Instrument the workflow — Run the Content Velocity by Workflow report to see hours spent per step per string and per word, then use the String Changes Report filtered to the approval step to check how many strings were actually changed there. A step where strings sit for days with no edits is a candidate for removal or for an idle rule.

These approval controls fit localization managers who...

  • Publish multi-language releases where every locale must go live at the same moment, not as each finishes.
  • Need to answer "who changed this translation, at which step, and by how much" months after publication.
  • Run marketing, legal, and product content through the same platform but with different approval depth for each.
  • Are measuring approval cycle time and want per-step hours rather than an overall job turnaround figure.
  • Have internal approvers who should accept or reject translations without rewriting them.

When approval workflow controls may not be the right priority

  • A program with one target language and one trusted reviewer can run Translation, Review, Published with default settings; hold steps and reject paths add configuration without adding control.
  • Teams whose real question is who should review and how sign-off is recorded by role are solving a staffing and permissions problem, covered on the human review workflow page.
  • Teams comparing platforms across file formats, connectors, pricing, and reporting should start with the translation project management platform comparison and treat approval controls as one criterion within it.
  • Teams whose bottleneck is deciding which content takes which path — machine translation versus human, edit versus skip — need routing rules, covered on the automated task routing page.

Evaluation checklist: questions to ask about a platform's approval workflow controls

Can an approval step be locked to approve-or-reject only, with editing disabled?
Look for a per-step setting that removes the ability to type in the translation field while still allowing Issues or quality errors to be logged. If approvers can always edit, the approved version and the linguist's version are never cleanly separated.

Where does a rejected string go, and can that target be chosen per step?
Confirm the platform lets a rejection return to a named step (an Edit step, for example) rather than always restarting at translation. Rejection targets determine whether a formatting fix costs a full retranslation.

Is there a hold step that releases everything at once?
Ask for a step that pauses all translated strings until a manager releases them, and whether a separate hold exists before translation for cost approval. These two holds are what make staged releases and budget gates possible without manual tracking.

Can publishing happen before the final step, and what does that do to translation memory?
Ask whether early publication is available per step, what triggers it (save or submit), and whether pre-published machine translation is kept out of the TM. Teams that pre-publish without understanding TM behavior end up with unreviewed MT in their memory.

What happens to a string that sits in an approval step too long?
Look for a configurable idle rule that can notify or auto-advance after a set period. Without one, delay is invisible until the due date.

What change history is kept, for how long, and can it be filtered by step and user?
Ask for a report showing the action that moved each string, the edit distance between steps, and the acting user, plus the retention window. A six-month, per-step, per-user history is a reasonable baseline; a job-level "completed" status is not an audit trail.

Can approval cycle time be measured per step, not just per job?
Confirm a report that shows hours spent in each workflow step per string and per word, by workflow and by locale. Per-step timing is what tells you whether the approval step or the translation step is the bottleneck. For the wider reporting picture, see which tools are best for localization reporting and analytics.

Can approved content be published back to the source system automatically?
Check whether the CMS or repository connector delivers translations when a job completes and whether it can publish them in the destination without a manual step. Smartling's WordPress connector, for example, has a setting to publish translated content automatically once it is returned; other connectors deliver translations back when the job completes, so confirm for each one whether publishing in the destination is automatic or a manual step.

How Smartling exposes approval workflow controls

Smartling treats approval as a set of per-step settings rather than a single review toggle. Under Project Settings, a workflow is built from typed steps — Translation, Edit, Post-Edit, Review, Internal Review, Transcreation Review, Quality Evaluation, Desktop Publishing, Pre-Translation Hold, Workflow Hold, and a Decision step — and the step type drives rate-card lines and job due-date settings, so an approval stage is priced and scheduled as a distinct piece of work. Internal Review is the step type built for an organization's own approvers and is completed in the CAT Tool; Review opens in Review Mode by default, a simplified interface for accepting or rejecting translations. Smartling's own quality guidance recommends enabling the reject function on internal review steps so a reviewer can send a string back to the original translator instead of rewriting it.

Each step's "Manage Step" panel carries the controls that define approval behavior. "Users can revise content" locks or unlocks the translation field. "Users can reject content to another step" names the exact step a rejection returns to, and "Users can reject and edit published content" governs whether a published string can be reopened. "Pre-publish strings" offers Never, On save, or On submit; pre-published human translations are saved to translation memory while pre-published unedited machine translation is not. TM Match Skipping advances strings past Edit, Review, Internal Review, Post-Edit, Quality Evaluation, or Desktop Publishing steps at a chosen match percentage, and the Idle String Rule sends an email or moves strings forward after a set time in a step. Workflows can be created at account level, where Account Owners maintain one set of approvers for every project, or at project level, where Project Managers keep vendor visibility to a single project, with a default workflow per target language.

Two records back the audit side. The String Changes Report, under Reports, lists every action that moved a string — TRANSLATION_SUBMITTED, EDIT, REVIEW, REJECT, MOVE, CUSTOM_MOVE, SMARTMATCH, IMPORT, POST_MACHINE_REVISION, and AUTO_MOVE_FUZZY_MATCH — with edit distance between steps, edit distance to the published version, and fuzzy score, filterable by project, workflow step, job, language, user, and authorization date for the past six months, with a CSV export for the full result set. In the CAT Tool, the Translation History panel shows the same actions per string with the name of the user who performed each one. For cycle time, the Content Velocity by Workflow and Content Velocity by Locale reports chart hours spent in each workflow step per string and per word, with time counted cumulatively when a string is rejected back into a step, and can be scheduled to send as PDF or CSV. Reviewer roles, Review Mode, and recorded sign-off are described on the human review workflow page; the platform-level comparison of how vendors handle stakeholder approvals is on which localization platforms handle stakeholder approvals most efficiently.

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 fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.