The author publishes version 3 of a high-traffic English article. The Spanish, German, and Japanese translations of version 2 are now technically stale, but the localization team finds out three weeks later when a customer complaint surfaces. ServiceNow Knowledge supports versioning and translation independently; tying them together is workflow you build, not configuration you turn on.
Translation is a derived artifact, not a sibling
Treat the source-language article as canonical. Translations are versioned copies that derive from a specific source version. The relationship is captured on the translated article via kb_knowledge_translation linking to the source sys_id and the source version number. When the source advances, the translation row records which version it currently reflects.
Source: KB0012345 v3 (en)
Translation: KB0012345-es v2 (sourced from v2)
Status: stale (source advanced from v2 to v3)Version-aware staleness flag
A scheduled job compares each translation’s source version against the current published version of the source article. If they differ, set translation_status to pending_review and notify the translation owner. Without this loop, stale translations remain “published” indefinitely and quietly mislead users.
Decide your staleness policy explicitly
Three policies are defensible. Strict: the translation reverts to draft until reviewed. Permissive: the translation stays published with a “this article was updated” banner pointing to the source. Hybrid: minor edits stay live, major edits revert. Pick one and document it in the knowledge base policy article — most teams default to permissive without realizing they did.
Workflow Studio handles the orchestration
Build a flow on the source article publish event that fans out a translation task to each language owner. The task carries the source version, the diff (where supported), and a deadline based on the article’s tier. Tier 1 articles get a 5-day translation SLA; long-tail articles get 30 days. Track completion against the SLA on a Performance Analytics indicator.
// Flow trigger condition on kb_knowledge update:
current.workflow_state == 'published' &&
current.workflow_state.changesFrom('draft') &&
current.kb_knowledge_base.translation_required == trueAvoid in-place editing of translations
When the translation team updates a Spanish article, the change should land via the same version mechanism — check out, edit, publish a new translation version. Editing in place breaks the source-version pointer and you lose the audit chain. Lock the translation table to prevent direct edits via ACL on kb_knowledge.update for non-source rows.
Implementation sequence
Start with one language pair end-to-end. Define the staleness policy, build the staleness detection job, wire one notification, get the translation team using it for two weeks. Only then expand to additional languages. Teams that try to roll out five languages on day one usually ship none of them.
Common failure modes
A translation marked published while its source is still in draft — block publish via business rule. Auto-translation tools writing directly to the article body without version awareness — use a staging field and a review step. Search returning the stale translation when a fresh source exists — boost the source version in search relevance until the translation catches up.
What changed in 2026
Now Assist’s translation assist (where licensed) can pre-fill the translation draft from the source diff, but the workflow gate still requires human review before publish. Treat the AI draft as a productivity aid for the translator, not a replacement for the workflow.
What to do this week: query kb_knowledge for published articles whose latest version is newer than any of their translations — that count is your stale-translation backlog.
