function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Couple of questions re: SFDC Knowledge

My company is in the process of investigating SFDC Knowledge as a repository for its (already sizeable) knowledge base.


In particular, we want to seamlessly integrate Articles with Cases.


I have a few questions about this:

1) Where are the links from Articles to Cases stored? I would expect there would be 'junction' objects, but the WebUI and the Dataloader seem to either obscure these objects or the implementation is different than I expect, or both... I am particularly interested becaus:

      a) We have a primitive way of linking Cases to Articles already and we'd like to preserve those relationships if/when we moved to SFDC Knowledge...

      b) Also, there would probably be a desire to see who made the Link from a Case to an Article and potentially to have some Triggers fire on creation of these Links.


As of right now, since the 'Link' object is obscured, I don't think I can do either.


2) Is there a concept of Versioning in the Articles? It would be valuable to be able to see an older version of the Body of an Article to see how its evolved. We're also interested in seeing who + when folks changed an Article... And this information would be stored in the Article Version (presumably). I see some things in the Dataloader, but I'm (at this point) guessing the significance of each visible table. Is there any documentation on Article Versioning? I haven't found any, but perhaps I'm looking in the wrong place(s).


Thank you for your time,
Daniel Fisher


we are just looking at knowledge too..


if you use eclipse to view the SFDC schema, you can see the objects underlying the document 'types' as typename_kav. (FAQ_kav for example)

each has a 'SourceID' field, which is a reference field to the related object.. Case is one of those.

the SFDC UI model supports listing objects that are related to the primary display type as an automatic function.


dataloader cannot resolve those references automagically.. you would have to provide that info.


the reference field appears 'optional', so when displaying the document types as the primary object, one could list and differentiate between docs with related cases, or not.


I don't see any data elements in the type_kav fields that would support versioning directly.





The details on the Knowledge related data model is available here:

And you can find the integration with the rest of the service cloud objects here:


Regarding versioning, it is not yet available, but it is in our plans (you can probably guess from the data model that we have been having it in mind since the beginning) it will appear probably sometimes next year.