This is based on Knowledge, not Lightning Knowledge which is quite different.
Knowledge editors need to have an additional Feature Licence to create articles. (Apparently $600/user/year).
- Knowledge can have Data Categories, that act like faceted or drill down search.
- Data Categories are very powerful. See Data Categories
- Each Data Category can be visible by different groups of users.
- You can have different Article Types which are like a separate object in SF that can have different fields.
- Knowledge can be visible to different groups of users, based on profiles.
- Public See Knowledge on Communities
- Each Article Type can be visible by different groups of users.
- Each field in each Article Type can be visible by different groups of users.
- Eg public can see the basic answer.
- Community users can see the an extended answer, and download attachments
- Staff can see even more information
- Knowledge can have approval processes just like every other record in Salesforce.
- Permissions can be given to users to Publish, Archive, Edit and Delete articles
- You can have articles in multiple languages.
See Salesforce Help here https://help.salesforce.com/HTViewHelpDoc?id=knowledge_implementation_tips.htm&language=en_US
Knowledge and Cases
- Add the Articles related lists to Cases, or it will appear in Case Feeds
- Functions much the same as Solutions.
- You can email a PDF attachment of the Knowledge article to users.
- See below re PDFs
- After you have you public knowledge base set up - set the Knowledge setting for Allow users to share articles via public URLs this then allows your staff answering cases to quickly create a link to the Article and send it to your client.
Articles about Knowledge
Setting up Knowledge
Setting up Knowledge is almost a case of knowing exactly how Knowledge will be used BEFORE setting it up.
Article Type Fields
By Default, Article Types DON'T have a field for the actual content of your Knowledge article - they only have a Summary field. Add a Rich Text field to store the contents of your knowledge article.
Using your Knowledge base from Salesforce1? DO NOT use Rich Text Areas UNLESS your articles will be under 1000 characters in length.
- Will you have a publicly visible knowledge base?
- Do you need more than one publicly visible knowledge base?
- Will you use Chatter Questions?
- Do you have a Partner and/or Customer Community?
- Do you want to use Knowledge for Internal users only?
- Are there articles that only certain people should be able to see?
- Is there particular content in articles that only certain people should be able to see (eg an Advanced section or an Internal section)?
- Will you have articles in multiple languages?
- Who are the users that will read/create/edit/approve articles?
- What is your internal workflow for publishing articles?
- Will knowledge be linked to cases?
- Do you have an approval process for knowledge articles?
The Implementation Guide has more details https://ap1.salesforce.com/help/pdfs/en/salesforce_knowledge_implementation_guide.pdf
- Answer all the questions above.
- Sketch out how you want the knowledge articles to appear.
- Decide on how many public knowledge bases there will be.
- Decide on the fields and create the Article Types
- Test what it will look like in ALL channels - see this example - the field named Rich Text Area is not a good look.
- Create your Public Knowledge Base - see Knowledge on Communities
- Enable Chatter on Articles (for internal use https://success.salesforce.com/answers?id=90630000000h0GpAAI)
Add a field to any Article Type that has a Public Knowledge Base. This gives the authors a quick link to the article in the public knowledge base.
IF( AND(ISPICKVAL(PublishStatus,"Published"), IsVisibleInPkb=true,IsMasterLanguage=true), Hyperlink("http://yourapp.force.com/yoursite/articles/en_US/Knowledge/" + UrlName + "/","Public Knowledge Link", "_blank"),"")
I think Visibility is both the most powerful and most confusing feature of Knowledge and Data Categories. Whether a person can see a particular field on a particular knowledge article depends on the settings in one or ALL of the following.
- Article Types
- Article Type fields
- Data Category Groups
- Data Categories
- Profiles (including Sites Profiles)
- Permission Sets
- Knowledge article Status
I can guarantee you that setting up knowledge for the first time you are going to have Visibility issues. Here's some things to try:
- Ensure the Default Data Category Visibility is set
- Set this restricted if the public KB will have a restricted set of Data Categories than Internal
- Ensure the Public Access Settings for the following are set:
- Data Category Visibility
- Article Type set to Read
- Custom Fields on the Article Type's Object (eg FAQ) set to Read
- See my note about Language in the Public Knowledge for Mobile, Web and Facebook - it stopped articles showing correctly.
- The article is created as the correct Article Type - yep, I did this.
- The article has the Data Categories set that correspond with the Data Category Visibility in the Public Access Settings
- The article Channel is set to Public Knowledge Base
Issues with Knowledge
- Unless you have Service Cloud and Console, you can't use the new Knowledge One sidebar on Case Feeds.
Creating Knowledge Articles
- Assigning Categories takes too many clicks (which is a good reason as to why there is only 3 Data Category Groups available).
- You can't create Categories on the fly.
- You have to assign Categories at their lowest level.
- You have to think about EVERY aspect of visibility every time you create a knowledge article.
- You can't clone Knowledge Articles. (Annoying!)
Rich Text Area Editor
- See https://help.salesforce.com/HTViewHelpDoc?id=fields_using_rich_text_area.htm&language=en_US - this is IMPORTANT to know about ALL The limitation before you create your knowledge base.
- Also see https://help.salesforce.com/HTViewHelpDoc?id=fields_using_html_editor.htm&language=en_US
- Grrr! There are NO Keyboard shortcuts for headings, bullets, numbering etc
- You CAN edit the source.
- You CAN insert multimedia Content
- Keep your content structure simple use only
- Use Relative Hyperlinks to other Knowledge articles (see Smart Links below).
- PDF attachments of honour permissions on fields. Say you have a field that only Internal users can see - here is an article explaining this. http://help.salesforce.com/HTViewHelpDoc?id=cases_send_articles.htm&language=en_US. Create a new profile that is used for this purpose and ensure that this profile does not have access to the fields that should not be emailed.
- The PDF's don't look that great. See Example Attached. (Although does this post say that it can be customised? https://help.salesforce.com/HTViewHelpDoc?id=cases_send_articles.htm&language=en_US)
- Images from external URLs don't appear in the PDF. But I guess that is the same as regular SF emails. You will have to upload the images to the Rich Text Area
- Attachments on the knowledge article are of no use when emailing. Possibly, rather than using attachments, add the files to Content (see Files, Content, Attachments etc.), and add them into the body of the knowledge article as hyperlinks.
- In Case Feeds for Service Cloud there is an option to email a link to the article. I would prefer that as an option. It does not seem to be in regular Case Feeds though.
Public Knowledge Base
Creating Knowledge Articles
- Use Smart Links between articles https://help.salesforce.com/apex/HTViewHelpDoc?id=knowledge_custom_field_rta_smartlink_manual.htm&language=en_US
- Know your audience
- Know your corporate style guide for tone and language for articles
- Keep formatting consistent - see these two articles on Gumtree for inconsistency
It is annoying and slow to create content in the SF RTE, so it may be easier to create the content in Word and paste it in. Unfortunately Word does not handle Bullets well, so you will have to re-format the bullets once you paste it in.
Alternatively you could use your favourite HTML editor but note that pastes the format EXACTLY with all the styles set in-line, so editing the content in the RTE after that may be a real issue. If you will ALWAYS create the content in the same app, then do so, but I would caution you to really keep the content simple.
If you have a HTML editor that produces very clean HTML with no styling then that is probably the best to use. The following are NOT the best because they paste the styling in:
- Google Docs
- Markdown for Mac pastes no styling in but pastes a lot of unnecessary formatting unless you paste the raw HTML
These ones are OK as they produce clean HTML
- One of the other Markdown to HTML tools.
Wherever you create the content, apart from autosaving as you go, don't save the content anywhere else as a backup, because then you need to maintain two versions of the content.
Solutions are the older way to do FAQs. Use Knowledge Now.
- On the Case go to the Solutions related list
- Enter a keyword in the search box next to the button View Suggested Solutions
- Click on Find Solution
- You may want to change the search string to find the right solution.
- Click on Select next to the solution to add it to the Case.