Salesforce Knowledge gives you the ability to build out a comprehensive Knowledge Base (KB) inside of Salesforce – a collection of articles with relevant information about your products and services, to encourage a self-service model for your customers to solve their own queries. Lightning Knowledge is simply Salesforce Knowledge in the Salesforce Lightning Experience.
As you probably know, Salesforce Lightning has “struck” almost everywhere, and Salesforce Knowledge is no exception. Lightning Knowledge is a major reworking of the Classic Knowledge features and is more than just a change in UI. This blog introduces you to the basics of Lightning Knowledge so you can plan your roll-out. I’ll also dive into how to migrate Lightning Knowledge so you and your team can feel prepared!
Key Points: What You Need to Know
Before we dive into the fun features of Lightning Knowledge, let’s knock out a few housekeeping items first that you’ll need to know.
1. Lightning Knowledge Migrations from Classic Knowledge
If you’re currently using Classic knowledge, this article will certainly help you plan out and organize your Lightning Knowledge setup. I’ve also included some considerations that you need to be aware of if you’re migrating to Lightning Knowledge and not just implementing it fresh.
2. Licensing
The licensing requirements for Knowledge are dependent on the edition of Salesforce you’re on and which clouds you have. For Essentials and Unlimited editions, Lightning Knowledge is available as a part of Service Cloud for no additional cost. For Professional, Enterprise, Performance, and Developer editions, Lightning Knowledge does have an additional cost associated. Contact your Salesforce Account Executive for more information on pricing.
3. Access Considerations
The Lightning Knowledge data model is very different from the Classic Knowledge data model, so the access is also fairly different. In Lightning Knowledge, all articles are on a single Salesforce object called Knowledge (Knowledge__kav) by default (you can actually rename if you want, not just relabel!)
Different article types are kept as Record Types, like any other Salesforce object. For example, you may have an FAQ record type, a Troubleshooting record type, and a News record type for the different types of content you want to organize. We’ll discuss that in more detail later.
Since everything works like a normal Salesforce object, access is given in much the same way. Users can read, create, edit, and delete articles based on their Knowledge object permissions. The main thing that gets tricky are the special Lightning Knowledge User Permissions that primarily focus on Publishing, Archiving, and Translating draft article versions. For a detailed breakdown of these permissions, Salesforce Help has a great table summarizing the permissions and their purposes.
Content Management
The Knowledge Lifecycle and Versioning
Giving your team access to provide feedback either via chatter comments, ratings, or (for super users/authors) directly editing drafts is critical to ensuring your knowledge base is polished for your customers. The Knowledge Lifecycle is cyclical and stresses continuous improvements to content.
To support the Knowledge Lifecycle, Lightning Knowledge has version control, which is a new feature from the Classic model. Now, each article will have a version number and when you need to make changes to a published article, you edit it as a new version and then publish it fresh. This lets you work on new content without impacting the published version that users see.
Salesforce also provides a convenient way to compare article versions with the Article Version Comparison component.
Channels
Once you have your articles published, you have several channels to share them with. These channels are like audiences for your content – Internal users, Partners, Customers, and the general Public.
Internal:
The internal channel is for internal users only. This is for content that your internal user base needs access to, such as company policies, onboards, internal Salesforce process documentation, etc.
Partner:
Partner shares the content with partner licensed users within a Partner Community. This is good for content you need to share with your partners such as sales process guidelines, tips and tricks for selling, or product updates.
Customer:
Along with Public, the Customer channel is one of the most popular channels because it is critical for customer self-service and case deflection. The customer channel shares content with users on a customer community license within a Customer Community. It’s great for customer-facing FAQ, troubleshooting articles, and step-by-step guides.
Public:
The Public channel is how you expose and share knowledge content with public (guest) users. This content can be shared on a public community page or site and is accessible to unauthenticated users. There are also Salesforce AppExchange Apps that let you expose public knowledge articles on non-Salesforce pages. Like with the Customer Channel, it can be a great way to empower customers to self-help and can assist with case deflection. For example, Internet Creations implemented a customized public knowledge base for Solarwinds MSP (formerly LOGICnow) which resulted in over 1000 cases deflected in a single month. You can also publish product announcements and marketing content to share with readers who may not be a customer yet.
Approval Processes
As with most Salesforce objects, you can create an approval process for articles. This is invaluable for controlling what content is published, especially if you have a public knowledge base and need to screen content for customer-facing articles. The approval processes for knowledge articles work more or less like any other, but there are special approval actions that are unique to knowledge – Knowledge Actions. For example, Publish as New publishes the article as a new version.
Knowledge Features
Ratings
One feature of Salesforce Knowledge is the ability to let your users rate the content. In Classic Knowledge this was always a 1-5 star rating, but in Lightning Knowledge it’s a simpler thumbs-up or thumbs down rating system (when migrating, 3,4,5 stars are converted to thumbs-up and 1,2 stars are thumbs-down). These voting buttons can be added or removed from pages as needed so you can control who can vote on what kinds of articles. For Lightning Pages, the Article Thumb Vote component gives users the voting options.
In a Salesforce community, the Allow Ratings is a setting on the Article Content component for the Article Detail page, which respects your community theme colors.
Data Categories
Two of the most critical features of Salesforce Knowledge is Data Categories and Data Category Groups. These are two major functions – article organization and article access. Data Categories allow you to organize your article content in a hierarchical way. They can also be grouped into Data Category Groups.
Let’s look at an example of how this could be structured; let’s say you have article content for your product information. You have several categories and subcategories of your products. You also have a global market and need to divide content regionally. Here’s how this could look with Knowledge Data Categories and Data Category Groups:
With this model, regions and subregions are hierarchical in the Region Data Category Group and product lines and specific categories of offerings are hierarchical in a separate Products Data Category Group. These Data Categories can now be assigned to articles to organize content by product and by region.
Another key feature of Data Categories is article access. Data Category visibility can be controlled via profiles and permission sets to ensure users only see knowledge content relevant to them. For example, maybe your Customer Community users have regional profiles. You can restrict their access to article content that is tagged with their region’s data category only so they aren’t seeing irrelevant articles in the knowledge base.
Note: Data Category access is different from the normal object and record hierarchical sharing and access we’re typically used to as Salesforce admins. When you give a user access to a data category, they get access to all data categories up and down the branch, but no access to sibling branches. Furthermore, a user has to have access to all the data categories of an article in order to view it, not just one. Make sure you read over Salesforce documentation to understand access before rolling it out to your users.
Topics
Adding topics to articles lets you easily classify them based on content and provides easier searching within your knowledge base. Think of these like keywords. A single article can have a multitude of topics assigned depending on the content (just don’t over-assign topics because then searches could return irrelevant results).
Topics are different from Data Categories in that they don’t drive article access in any way and they are not hierarchical. They are primarily used to organize information within a knowledge base in a community.
Topics are assigned to articles in Content Management > Topics in the Salesforce community workspaces. There is also a setting to automatically assign topics based on certain data categories, which streamlines the tropic assignment of new articles and makes manual tagging more automated.
Case Deflection
With customer support teams feeling overwhelmed, Salesforce can help manage the high support volume and Knowledge is one of the methods. Exposing knowledge articles to your external and public users is a great way to deflect support cases from your service agents. A robust knowledge base will empower your customers to self-service rather than flooding your case queue with questions. Salesforce makes this even better by providing the Case Deflection component for communities.
The Case Deflection component lets your users submit cases but a right-hand panel recommends knowledge articles based on the text being typed into the case. The component also generates deflection metrics so you can see how effectively the component is working.
Using Apex with Knowledge
One final important feature of Knowledge is that it can have Apex triggers and be accessed through Apex code. In fact, there are standard apex classes relating to knowledge management that can be called in Apex for publishing, archiving, searching, and more. In Classic Knowledge this was more restrictive, but the Lightning Knowledge data architecture change included these development improvements. If you have a use case for development and Lightning Knowledge, Salesforce has more information in their developer guide.
Migrating to Lightning Knowledge
As you likely know, making the move from Classic to Lightning can be a major undertaking. But there are many reasons why it’s better to move sooner than later. Lightning Knowledge is one of the major Lightning Experience changes that actually results in a data architecture change. We’ll get into the details in a moment, but the main thing to keep in mind is that Lightning Knowledge now functions more like normal Salesforce Objects (awesome!)
3 Things to Consider Before You Start
There’s a lot to think about when prepping for a Lightning Knowledge migration. Here’s 3 of the things we find most important.
1. Is your org ready for the migration?
Before embarking on the Lightning Knowledge transition, you want to make sure your org and your users are ready for the move. Knowledge changes in the Lightning Experience. As a result, Lightning Knowledge isn’t accessible via Classic. If you still have users that aren’t in Lightning yet then they will lose access to Knowledge articles. If you need help getting your team into Lightning so you can use Lightning Knowledge, Internet Creations can help you get started.
2. What needs manual updating during migration?
The Salesforce Lightning Knowledge Migration Assistant definitely helps a lot with the migration to Lightning Knowledge. However, there’s also some manual work required. Depending on the customization you have in your org, you may need more or less of this manual work. Make sure you review all the items you’ll have to do manually before starting finalizing the timeline and Go Live date so you know you have enough time to do the necessary steps.
3. Your migration timeline
Since Lightning Knowledge is a major architecture change and cut-over from Classic to Lightning, you have to ensure your Go Live plan and timeline are thought through. There are several steps that have to be taken to perform the migration fully in a Sandbox and then in production (a Sandbox migration is required by Salesforce) and depending on how many things require manual updates you may have a lot to prep. Laying out the major items you’ll have to do and allotting times to them will help you determine a realistic timeline. To help get you started, here’s the basic steps all orgs have to go through.
- Review what you’ll have to do manually. This is more prep work to help you determine project scope and timeline, but it can be fairly time consuming if you have a lot to review. We’ll dive into the details on this next.
- Run through the migration in a Sandbox. Full Sandboxes are best so you get an accurate dry run of the migration.
- Reach out to Salesforce support to enable the Migration Assistant in production. Sounds simple but it isn’t necessarily that easy. More on this in the “gotchas” section.
- Train your users, especially authors, on how to use Lightning Knowledge.
- Regression test in your Sandbox. Including things like public knowledge bases and any processes that rely on Knowledge content.
- Perform the migration in Production. A previously-agreed-upon maintenance window is recommended.
- Smoke test in Production to make sure nothing went wrong!
What Migrates and What’s Manual?
To elaborate a little on #3 up above, let’s review some of the items that won’t migrate automatically. This list can help you build out your own checklist based on our own org’s configuration.
What Migrates
| Item | Notes |
|---|---|
| Related records | The migration assistant moves and consolidates related records, such as links to cases, data categories, votes, views, and Article Feed. |
| Page layouts | These migrate over normally, but admins should confirm they are correct after migration. |
| Compact layouts | These migrate over normally, but admins should confirm they are correct after migration. |
| Custom fields | Custom fields are automatically created on the new Knowledge object based on your previous article fields. But be careful -- there are some “gotchas” surrounding field migration (see below). |
What Doesn’t Migrate
| Item | Notes |
|---|---|
| Article numbers | Due to limitations of Auto-Number fields, Article numbers will reset/change during migration. |
| Version History | Version history doesn’t move over to Lightning Knowledge, so be sure to back it up if you need it for retention policies. |
| Article Actions | Admins must reassign article access for publication, etc. after migration. |
| Dependent picklists | If you have any picklist dependencies on Classic knowledge articles, these have to be recreated after migration. |
| Formula fields | Formula fields do not migrate cleanly and need to be audited and corrected after migration. |
Migration ‘Gotchas’ – Look Out!
At Internet Creations we’ve done a lot of Lightning Knowledge migration projects, both big and small! We’ve even migrated our own knowledge base, which was over 12 years old, to Lightning Knowledge. We’ve seen a lot throughout these projects and we want to help you learn from our experience!
Getting the Migration Assistant Enabled in Production
The Lightning Knowledge Migration Assistant is enabled by default in sandboxes, so you should have no trouble testing it there. However, you have to ask Salesforce to enable it in Production. This may seem simple, but Salesforce will actually ask you a series of questions that you need to be prepared to answer. We’ve also seen some delays in the past with certain questions stalling projects. Waiting too long to ask Salesforce to enable the tool can cause project timeline issues, so it’s best to prepare in advance!
The questions Salesforce will ask you are listed in this Salesforce knowledge article. It’s recommended you review them and make sure your team is aligned on the answers in advance!
Changing Record Types
This is a sneaky gotcha that, unfortunately, isn’t obviously documented in a lot of Migration Assistant documentation. There’s a restriction on Salesforce Lightning Knowledge articles that prevents you from updating the Record Type from a published article. You can’t even Edit as Draft and change the record type on the daft. You can only update record types on net new articles.
Why is that such a big deal? This means that whatever record type your converted articles are assigned when they are migrated is the record type they’re stuck with! The only way to change them would be to clone it as an entirely new article, change the record type, and then publish fresh. Not only is this tedious, but ratings, related records, etc. won’t move over to the new article.
When you migrate knowledge articles, the Migration Assistant will automatically create new Record Types with names that match the original Article Type names. This is good news if your Knowledge structure isn’t changing with the migration. But this is a major “gotcha!” if you’re planning to reorganize your record types in Lightning Knowledge. Make sure your Classic Knowledge Article Types mirror your desired Record Type format for Lightning Knowledge.
Custom Field API Names
Another migration gotcha surrounds the API names for custom migrated fields. The Migration Assistant is smart and will recreate custom fields on the Lightning Knowledge object and migrate the data from those custom fields over to the new fields. Word of warning though, to avoid the possible error of duplicate API field names, the Migration assistant prefixes the new custom fields with the Article Type name.
For example: You have two article types — News and FAQ. News articles have a custom field called Abstract__c and FAQ articles have a custom field Question__c. When these migrate, they will become News_Abstract__c and FAQ_Question__c, respectively.
File Fields
One feature of Classic Knowledge that doesn’t exist in Lightning Knowledge is the concept of file fields. File is a field type option on Classic Knowledge articles that would allow for the uploading of an image or document to the article. These fields could be used for things like article thumbnails, etc. These don’t exist in Lightning Knowledge, and the files uploaded to these fields are moved to normal Salesforce Files by the Migration Assistant. This is something to be prepared for, especially if you have multiple different file fields for different attachments or are using the file fields in custom code.
API Name References on OLD Salesforce Sites
If you’ve never had a public knowledge base or your knowledge implementation is fairly new (less than 5 years old) then this probably won’t be an issue for you. But if you’re like us — a 12 year old public knowledge base — then heads up! Sometimes old, archived Salesforce Sites that hosted knowledge in the past can still be referencing Classic Knowledge API on the backend. The Migration Assistant can’t help with these old Salesforce Sites, and sometimes Salesforce Support has to get involved to help. This is one of the many reasons it’s so important to do a test run of the migration in a sandbox, so you can uncover these little surprises earlier than later!
Lookup Filters for Knowledge Articles
One final Lightning Knowledge quirk that could surprise you during implementation is that lookup filters are not supported for lookups to Lightning Knowledge. If you have a lookup field pointing to Knowledge, you can put a filter in place but the filter will only error upon save and not actually filter the results being shown, creating a poor user experience. There’s not really a great workaround for this and is just something to keep in mind if you ever have a requirement to filter lookups to Knowledge articles.
Keep Learning!
Lightning Knowledge is just one facet of the Lightning. To learn more about the Lightning Experience you can check out some webinars and other blogs on the topic!
Become a Master Lightning App Builder
Lightning Champion Benjamin Bratcher shows you why the Lightning App Builder is one of the best Lightning features!
The 6 Best Features for Customized Productivity in Lightning Experience
One of the major benefits of moving to Salesforce Lightning is increased productivity. The true magic behind the power is the customization. Learn about some of our favorite features!
3 Tips to Maximize In-App Guidance for Salesforce Lightning
Introducing the In-App Guidance for Lightning Experience which was part of Salesforce’s Winter 20 release.
Trailhead is another great place to get more training on Salesforce features and get hands on in a Trailhead org! Here’s a great place to start, including some help on how to migrate:
Knowledge Basics for Lightning Experience
Lightning Knowledge Setup and Customization
Comments: