Exporting Salesforce Knowledge articles: versions, languages, links

What are you actually exporting when you export Salesforce Knowledge articles?#

You are exporting article version records, not single pages. In Lightning Knowledge every article is a parent record (Knowledge__ka by default) with one or more version records (Knowledge__kav), and each draft, published version, archived version and translation is its own version row with its own ID.

Three identifiers matter. The article ID ties all versions together. The version ID points to one specific version. The Article Number identifies a primary article and all of its translations, so it is not unique per row. A clean export keeps all three, plus the version number and language, so you can rebuild which text was live in which language at a given time.

Lightning Knowledge also replaced Classic article types with record types on one Knowledge object. If your org migrated from Classic, older documentation and scripts that reference article types will not match what you see now, and the record type is the field that tells a How-to article from a FAQ or troubleshooting article.

Which Salesforce export route fits knowledge articles?#

For a complete, queryable copy, use a SOQL export through Data Loader or the API; the translation export and the weekly export each solve narrower problems. The table compares the routes Salesforce documents.

How do you export Salesforce knowledge articles with Data Loader or SOQL?#

Run one export per question: a versions export from Knowledge__kav, a categories export, and a case-link export, each with an explicit filter. Data Loader runs SOQL against any object your user can read, and Export All adds soft-deleted records; the step-by-step mechanics are in the Data Loader guide linked below.

Filter on a single PublishStatus value per run, as Salesforce recommends. Since API 47.0, a query with no PublishStatus filter returns draft, published and archived versions when Lightning Knowledge is enabled, which silently mixes unreviewed drafts into a dataset. Your export user also needs the View Draft Articles or View Archived Articles permission to see those versions at all.

An illustrative published-version query: SELECT Id, KnowledgeArticleId, ArticleNumber, VersionNumber, Language, Title, UrlName, LastPublishedDate, RecordTypeId FROM Knowledge__kav WHERE PublishStatus = 'Online' AND Language = 'en_US'. Add your org's body fields (often a rich text field such as an answer or resolution field) after checking the names with a describe call, since they differ by org.

For archived versions, Salesforce documents querying by article ID with IsLatestVersion set to false. If you filter articles WITH DATA CATEGORY, the query must also have a WHERE clause on PublishStatus or Id.

• 1Run 1: Knowledge__kav, PublishStatus = 'Online', every active language
• 2Run 2: Knowledge__kav, PublishStatus = 'Archived', only if the history matters for your purpose
• 3Run 3: Knowledge__kav, PublishStatus = 'Draft', usually kept out of any dataset and exported only for an inventory
• 4Run 4: Knowledge__DataCategorySelection, all rows
• 5Run 5: CaseArticle, all rows, if case links are in scope
• 6Run 6: ContentDocumentLink for article IDs, if attached files are in scope

Which article versions should you export: published, draft or archived?#

Export published versions by default, archived versions when the history of what customers were told matters, and drafts only for an inventory. Drafts have not passed your review process, so they can contain wrong answers or internal notes that were never meant to leave the authoring team.

Archived versions are worth a deliberate decision because they are limited. By default Salesforce stores up to ten versions of an article, plus any versions attached to cases, and a case keeps the version it used, flagged as outdated, after a newer one is published. If you want a record of how an answer changed over years, export before older versions roll off.

Field-level history is shorter still. Article history tracking records field updates, publishing events and language versions for up to 18 months, and only from the day tracking was turned on. Treat the version rows themselves as the long-term history and history tracking as a recent audit trail.

How do languages and translations come through in a knowledge article export?#

Each translation is its own version row, so a multilingual export has one row per article, version and language. The primary-language version carries IsMasterLanguage = 1; translations share the Article Number with it, which is how you group them.

Export each language on purpose rather than taking whatever the query returns. Record the language code on every row, keep the primary version next to its translations, and note translations that lag behind the primary version, because a translated answer can describe an older product state.

Export Articles for Translation is a different tool. From a translation queue it exports all or only updated articles and creates a separate .zip file for each article type in each language pair, with limits of 50 exports in 24 hours and 15 pending exports. It is designed to round-trip work to translators, so keep its file structure intact and do not treat it as your archive.

How should data categories and channel visibility be handled?#

Export data categories as their own table and channel visibility as fields on every version row; both decide who an article was written for. Category assignments live in Knowledge__DataCategorySelection records, one row per assignment, which you join back to versions by ID.

Channel visibility tells you the intended audience. Salesforce maps the channels to the internal Knowledge app (App), the public knowledge base (Pkb), the Customer Portal (Csp) and the Partner Portal (Prm), and the version records carry matching visibility flags (for example IsVisibleInApp and IsVisibleInPkb; confirm the exact field names with a describe call in your org). An article visible only in the internal app often contains workarounds, escalation paths or system names that were never published, so it needs a stricter review than public help content.

What happens to images, attachments and case links?#

Rich text bodies, files and case links each need their own export and checks. Inline images in rich text fields are referenced from the HTML, so confirm in a test export whether the image URLs still resolve outside your org before relying on them.

Attached files are linked to records through ContentDocumentLink, one row per file and record, queried by LinkedEntityId. Salesforce states that Data Loader does not support exporting attachments and points to the weekly export for those. Plan a file manifest that maps each file to its article version.

Case links come from CaseArticle, which represents the association between a case and a knowledge article. These rows are what turn a help center into a retrieval or answer-quality dataset: each link records that this article was attached to this case. Export them with the case ID, article ID and the version the case used, then see the companion guide on exporting case history for the case side.

Knowledge article export checklist and manifest row template#

Use this checklist before any export leaves the org, then log each file with the manifest row below. It assumes Lightning Knowledge with default object names; adjust names after a describe call in your org.

What should each manifest row record?#

Write one manifest row per exported file so a reviewer can see exactly what left the org and reproduce it. The values below are illustrative.

Can published help content go into a licensed support dataset?#

Sometimes, but being public does not make help content licensable. Access to export the articles, privacy permission for their contents, ownership of the text and images, and the contractual right to license them are four separate permissions, and each needs its own answer; the full framework is covered in the guide on data privacy and the right to license business records.

Ownership is usually the easiest part for articles employees wrote as part of their jobs: under U.S. copyright law a work made by an employee within the scope of employment is a work made for hire, and the employer is the author. Contractor-written articles, vendor documentation pasted into answers, stock or vendor screenshots, and customer quotes may belong to someone else or come with restrictions.

Privacy and confidentiality review still applies. Screenshots can show customer names or account data, internal-only articles can reveal security or escalation procedures, and case links connect articles to customer records. De-identifying content does not create a right to license it; counsel should review the specific articles and agreements.

If you are weighing whether a knowledge base and its case links could support a data licensing deal, SourceX is the enterprise data transaction layer for AI and runs rights review, contracting, preparation and delivery for businesses licensing operational data. The first step is a short company assessment with no data uploads, and the company approves exactly what is released, once per deal. This guide uses Salesforce's own tools: you or your admin run the exports described here with Data Loader, the API or Setup.