Salesforce Knowledge (built on the newer Lightning Knowledge data model) lets a support team write, categorize, and publish articles that Service Cloud suggests to agents working a case and that customers can find through a self-service portal or public help site. It's a real, mature feature, and a lot of Service Cloud orgs aren't running it at all, since Knowledge is its own add-on license in many editions, separate from the base Service Cloud seat. Where we come in is making sure the content it serves up is actually current, not just well organized.
An article in Salesforce Knowledge is a record, categorized by Data Category (product line, topic, audience) and tracked through a draft-review-publish workflow like any other content system. Lightning Knowledge treats articles as a standard object with record types, which replaced the older Classic Knowledge model's custom article types, so newer orgs get a more flexible setup out of the box.
Once published, Service Cloud's case view can suggest relevant articles to an agent based on the case's fields and content, and the same articles can be exposed to customers directly through an Experience Cloud self-service portal or a public help site, so a straightforward question gets answered without opening a case at all.
Knowledge is genuinely good at the structure: writing, organizing, and surfacing the right article to the right case. What it has no way of knowing is whether the article's content still matches reality outside Salesforce. A troubleshooting article referencing a product's current firmware version, a warranty article referencing a policy that changed last quarter, a pricing FAQ that hasn't been touched since the last plan update, none of that updates itself just because the record it describes changed somewhere else.
That's the gap custom work closes: connecting the systems that actually hold the current truth, a product catalog, a billing system, a policy engine, so an article's content, or at least the specific fact inside it, stays accurate without someone remembering to go edit it by hand every time something changes upstream.
Knowledge's case-based article suggestions get layered with real account and product data, so an agent sees the article for the specific product version or plan the customer actually has, not a generic one.
A specific fact inside an article, a current price, a warranty term, a firmware version, pulls live from the system that actually owns it, instead of waiting for someone to notice it's out of date.
Tell us which Knowledge articles reference numbers or statuses that change elsewhere in your business, and we'll scope what it would take to keep them current automatically.
Tell us which articles reference something that changes outside Salesforce, a price, a policy, a product spec, and we'll map out what it would take to keep that content current automatically. And if the manual upkeep that's actually costing your team time is somewhere else entirely, we build on whatever that is.
Let's talk →Salesforce's built-in system for writing, organizing, and publishing support articles, both for agents working cases and for customers through a self-service portal or public help site. It's built on the Lightning Knowledge data model in current orgs.
In a lot of editions it's a separate add-on license, not something every Service Cloud seat gets automatically. Exact licensing and cost change by edition, so check current Salesforce pricing directly rather than assuming it's bundled.
Classic Knowledge used custom article types defined per content category. Lightning Knowledge treats articles as a standard object with record types instead, which is more flexible to set up and is the model Salesforce has moved newer orgs toward.
Yes, based on the case's fields and content, Service Cloud's case view can surface relevant articles to an agent. How relevant those suggestions feel still depends on how well-categorized and current the underlying articles are.
Not on its own. An article's content is written and updated manually unless something's been built to connect it to the system that actually owns a given fact, like a product catalog or a pricing table, which is custom work on top of Knowledge, not a built-in feature.