You are here:
Plan Your Knowledge Base in Lightning Experience
It's important that you consider your individual company’s needs while you develop a strategy for capturing and publishing your support team’s expertise. With a robust knowledge base, customers receive service faster or even solve their own issues.
Required Editions
| Available in Lightning Experience. View supported editions. |
| Consideration | Further Information |
|---|---|
| What types of articles and information do you want to include in the knowledge base? | Set Up and Configure Lightning Knowledge. Record Type Considerations for Lightning Knowledge, Page Layout Considerations for Lightning Knowledge, Custom Fields on Articles |
| Who can write the articles? Who needs access to read the information? | Lightning Knowledge User Access, Authoring Actions in Lightning Knowledge |
| Do you need to categorize your information? | Work with Data Categories, Data Category Visibility |
| Do you need to enhance search? | Improve the Article Search Experience, Enable Topics for Articles |
| Do you need workflow or approval processes to manage article creation and publication? | Workflow and Approvals for Articles, Validation Rules |
| Do you have an existing Knowledge base or documentation that you need to import? | Import Existing Information into Salesforce Knowledge |
| Are you supporting more than one language? | Support a Multilingual Knowledge Base |
| Do you need support reps to follow articles in Chatter? | Feed Tracking |
| Do you need to share your knowledge base externally? | Give Customers Access to Your Knowledge Base Through Help Center |
| Do you need guidelines, resources, and current discussions on the evolving world of knowledge orientated service? | Salesforce Knowledge is "KCS Verified" by the Consortium for Service Innovation, which recognizes best practices in customer support methodologies. By implementing Knowledge-Centered Support (KCS) features, you can create more efficient collaboration within your team and provide pertinent and accurate information to your customers. |
Consider the following tips when planning and using Salesforce Knowledge:
- Create synonym groups in Salesforce Knowledge. Synonyms are words or phrases that are treated as equivalent in article searches, letting you optimize search results.
- Before setting up data categories, carefully plan your category groups and their hierarchies. Also, consider how your category hierarchy maps to your role hierarchy. For more information, see Data Category Visibility.
- Create custom reports on your Salesforce Knowledge data. You can also install the Knowledge Base Dashboards and Reports app from the AppExchange to receive over two dozen helpful reports.
- Multiple support reps can edit the same article at the same time. If that occurs, your changes can be overwritten by a colleague without warning, even if you save your work frequently. To avoid accidental data loss, instruct all users who edit articles to edit only the articles they're assigned.
- Review your usage regularly to avoid storage shortages: from Setup, enter Storage Usage in the Quick Find box, then select Storage Usage.
- Public knowledge base users cannot rate articles.
- Salesforce Files allows support reps to attach documents to articles.
- You will lose your data if you convert a custom field on an article type into any other field type. Do not convert custom fields unless no data exists for the field.
- When renaming Salesforce Knowledge labels note that standard field names, like Title and URL Name, are fixed. You can’t change the labels for these fields on the article create and edit pages. If the organization is set to another language, these fields remain in the fixed label for that language.
- The Salesforce Knowledge search engine supports lemmatization, which is the process of reducing a word to its root form. With lemmatization, a search can match expanded forms of a search term. For example, a search for running matches items that contain run, running, and ran.
- Make sure that you have a clear understanding of how record types affect your knowledge base, and how to use them to display different layouts for different articles. For more information, see Record Type Considerations for Lightning Knowledge
- Determine if you need to create automation for some of your record types. Automation can include quick actions, process builder, or flows. For example, you can create a rule that sends an email to an article manager when a support rep creates an article from a closed case.
- Determine if you need to create approval processes for some of your record types. For example, if you have a type of article that must have legal and management approval before it can be published externally, create an approval process for the article type. For more information, see Workflow and Approvals for Articles.
Knowledge Base Allocations by Edition
The following table lists the total minimum number of languages, articles, and versions per article permitted for each Salesforce edition by default. Each Salesforce edition also has a default maximum number of languages, articles, and versions per article, as well. You can view the default maximum limits here. For orgs created before the Spring '18 release, the default limit for all editions is 16 languages. To request an extension for these allocations, contact Salesforce support.
| Edition | Article, Version, and Language Allocations |
|---|---|
| Essentials | 500 articles, 10 versions per article, 1 language |
| Professional | 500 articles, 10 versions per article, 1 language |
| Enterprise | 50,000 articles, 10 versions per article, 5 languages |
| Developer | 50,000 articles, 10 versions per article, 5 languages |
| Unlimited | 150,000 articles, 10 versions per article, 10 languages |
If you require more than the allocated default maximum, you can ask Salesforce Support to increase the article limits. Limits on versions retained per article don’t include versions linked to objects such as cases, work items, and undeletable lookup fields. So, for example, an article might have 25 versions, even if the default limit is 10 versions per article, if 15 of those versions are linked to cases. However, versions attached to objects such as cases count towards the total number of versions per org.
