The Knowledge Restore Lifecycle

This article describes the default behavior for restoring Knowledge articles and article versions when the One Version Per Push setting is turned off. The process works in batches, grouped by version number (e.g., CopyStorm/Restore restores all Version 1s, then all Version 2s, and so on).

Before restoring anything, CapStorm looks at all the article versions selected for recovery and sorts them into a very specific order. This “smart selection” prevents errors. The order of importance is:

1. Archived Articles First: It deals with the oldest, completed versions first to get them out of the way.
2. Online Articles Next: These are the active, published versions.
3. Drafts Last: Finally, it handles any unfinished drafts.

Within each of these groups, it follows another important rule: Master language articles always go before their translations. Original articles must be restored before their Spanish or German versions can be added.

No matter what an article’s status was in the backup—even if it was Archived or Online—CapStorm will always create it as a Draft in the new Salesforce org. This is a rule from Salesforce that CapStorm follows carefully.

After this phase, there is a collection of new Draft articles, all sorted and created in the right order.

Right after a new Draft article is created, CapStorm immediately checks its original status from a backup.

If the article was originally Online or Archived, this phase changes its status from Draft to Online.

Every article has to pass through the Online state before it can be archived.

So, at the end of this phase, all the articles that need to be restored are now sitting in an Online state in Salesforce.

This phase is the final cleanup crew for the entire restore job. It only begins after every other record for every table has been restored.

The main reason CapStorm waits to archive articles is to protect translations and different versions of the same article.

Here’s how it works:

1. Wait Until the End: At the very end of the job, this process scans for any articles that are currently Online in Salesforce but should be Archived.
2. Perform a Safety Check: Before archiving an article, it does one final, important check. It looks back at a CopyStorm backup to see if there are any other versions of that same article that haven’t been restored yet.
3. Archive or Wait: If all versions have been restored, it safely changes the status from Online to Archived. If it finds that other versions are still waiting to be restored (perhaps in a future job), it will leave the article Online to avoid causing problems.

After this final phase, the Knowledge Base now correctly matches the state of the backup. Online articles are online, and Archived articles are archived, with all their translations and versions correctly linked.

This careful, three-phase process ensures that even something as complex as Salesforce Knowledge is restored safely and accurately every time.

When the setting, “One Version Per Push” is enabled, the restore lifecycle becomes simpler, and the “Final Archiving” phase described above is no longer needed.

With this setting on, the archiving process happens automatically and sequentially. When CapStorm creates a new version (e.g., Version 2) from the currently online version (Version 1), the Salesforce method it uses automatically archives the previous version (Version 1) as part of the action.

In this mode, archiving is handled one version at a time with each step, rather than all at once at the very end of the job.

Here are a few things to keep in mind when restoring Knowledge articles:

• “Unpublish Article” in History: When CapStorm creates a new version of an article, it uses a specific Salesforce method that supports translations. A side effect is that there may be an “Unpublish Article” entry in the new version’s history. This is expected and is a result of the method required to maintain translation relationships.
• Deleting Drafts Can Be Risky: Be very careful if Draft versions of an article are manually deleted in Salesforce. If there is no currently Online version of that article (i.e., all other versions are Archived), Salesforce will delete the entire article and all its versions. This is a Salesforce platform behavior.
• Batching Articles with Different Owners: If a batch of articles are being restored that have different owners, it may result in a generic “unknown exception” from Salesforce. To resolve this, there are two options:
  1. Go to the “Advanced Parameters” for the __kav table in the  restore job and set the Batch Size to 1.
  2. Ensure that all articles being restored in a batch share the same owner.
• Links in Rich Text Fields: If articles contain rich text fields that link to other Knowledge articles, those links may be broken on the first version that is restored. This is because the process that fixes links runs before the records are inserted, so it cannot see other new articles that don’t exist yet. The links should be corrected as subsequent versions are restored.
• Images in Rich Text Fields: If a rich text field contains an image that fails to process for any reason, Salesforce may delete the image and all text that comes after it in that field.
• More on Rich Text Fields