I just completed migrating knowledge base for one of our Customers from their existing setup to Salesforce. The reason for migration was simple, they wanted to leverage the in-house capability of Salesforce to build a Community and they wanted their knowledge base to be a part of this setup. In short, all Knowledge at one place.
So here are the key points to remember, while migrating knowledge base:
1. Legacy Id is your friend. Capture it.
Whenever, you are planning for any migration, don’t forget to capture Legacy Id. It helps you to keep data in sync if required, going forward.
2. Capturing user and timestamp information:
Though, Salesforce has ability to make certain system fields writable after registering a case, however, while working with Knowledge base, you will notice that you can’t really set value for CreatedDate, LastModifiedDate and LastModifiedBy. I don’t know the exact reason, but it is what it is. In this case, we opted for storing such legacy data in custom fields and you can update these custom fields using process builder OR workflow rule, whenever user updates it in SFDC instance.
So, in case of Knowledge Base, there are 2 other date fields, which comes in picture: FirstPublishedDate and LastPublishedDate. Again, these fields are not writable, and so you have to opt for combination of custom fields and formula fields to show applicable values.
Eg. Store legacy information in custom field and create 2 formula field for FirstPublishedDate and LastPublishedDate
For FirstPublishDate, it will always remain same, so if you are capturing legacy id, you can use IF logical operator to show either custom FPD field OR standard FPD field.
For LastPublishedDate, your formula should be little advanced:
IF(ISBLANK(LegacyID), LastPublishedDate, IF(CUSTOM_LPD < LastPublishedDate,CUSTOM_LPD) )
In our case, we needed to modify/published Article several time in migration due to several reason, and so we opted for another way, anything that is published after Go live date, will show standard, else CUSTOM_LPD.
3. CreatedDate and LastModifiedDate are not available in Formula field. Ugh!
This is another surprise, we came across that CreatedDate and LastModifiedDate aren’t available in formula fields, so if you are planning for anything that utilize these fields in formula, stop thinking about that and opt for some custom way i.e. store Created and LastModified Dates in custom fields.
4. Migrating data to Rich Text Fields:
The standard way suggested by SFDC to migrate article is here:
I will not write anything explaining above link, as it is already quite self-explanatory.
However, one thing, I would like to share here is, this approach is good, when you have no data for rich text field OR you have very limited articles with rich text field. The reason is, it asks us to create HTML file for each article and store in one folder. And when you are importing articles, ZIP all the necessary files and upload using Import wizard provided by SFDC. Now, if you have very few articles, you can definitely create HTML files manually. What if you have 500? Now you will start thinking about it, and what if you have 5000? Don’t worry, we have solution for you.
Whenever you need to create articles with RTF fields involved, Just create Text area long field while you are migrating the data and push HTML content to that field. You can use data loader for migrating articles. Once articles are imported, convert that field to RTF field. It will ask for certain question, as if the existing data holds any HTML data? Just say, yes and you should be all good.
5. Importing multi-language article:
Another pain, as you can’t import article with translations using Data loader. You have to use the standard way of SFDC to import articles with translations given here:
Now, you would start thinking, what if you have multi-language article with RTF field?
Well, we don’t have very accurate solution for now, but this is what we have done. We have imported multi-language article using SFDC standard approach with just few placeholder fields and WITHOUT RTF field value. It will create article and translation record. And then you can extract that data (including Id of article) using data loader. Once extracted, you can map those articles/translation with their RTF body using vlookup using Legacy ID. Once a CSV is ready with SFDC article/translation ID mapped with RTF field info, utilize approach mentioned at point 4 to update article/translation.
6. Limitation with Microsoft excel:
When you are importing article using CSV file and your RTF field is holding really large data, you will end up seeing it in multiple rows and your CSV will be corrupted. Reason behind that is, excel is having limitation in terms of number of characters per cell, which is 32,767 (this may change with upgraded version of setup). So, please make sure, in case of large data, you scan your CSV before actually importing data, as this may end up consuming too much manual effort.
7. Handling special characters:
This is very common, when it comes to migrating knowledge articles. Check out this link to make sure, you are handling special character while importing data.
8. Leverage Publishing Service class
You may come across situation during knowledge import where you have go for bulk update on article, if you have missed something. But then you realize that you have already published those articles. Hack!! You can’t directly update published article. You have to bring each of those to draft version and make modification and publish them again. Well too much manual effort. Well, I can’t really reduce the time effort, but we can certainly automate this process to bring article to draft mode and publish it, while you are preparing bread-butter in kitchen. I would suggest you can write a small piece of code OR batch which will utilize methods from Publishing Service class make your life easier. Check out this detail of this class:
One thing to keep in mind is, every method, which update something in backend count against DML, so code accordingly.
Contributed by: Nishant Sharma