On the Mapped Application Service form there's a related list called "Knowledge Articles" that we wo

[venkat6490]

There are two possible related lists for knowledge on the Service Offering form in the baseline:

• Knowledge - this brings back all of the Knowledge articles that contain this Service Offering in their "Configuration item" field. You should not create records on this list as that would require creating a new Knowledge article, and that should be done from the Knowledge application as there may be an approval/publish process. Enter the Service Offering in your new KB Article and it will automatically appear in this related list. Access is controlled based on the user's rights to create or edit Knowledge Articles, which are usually controlled by the "Can Contribute" related list on the relevant Knowledge base, plus the user requires some form of knowledge role.
  
  
• Related Knowledge - this uses the many-to-many table Knowledge Related to Product [m2m_kb_ci] table, allowing you to relate many KB articles to a CI, and vice versa. The main difference here is that you need to refer to a KB article within the Service offering, or refer to the Service Offering within the KB article, so is generally a more scalable way of managing knowledge (which is what many-to-many tables are for). The New and Edit buttons are there by default - again you many prefer to hide the New button as it will create a new KB article when on the Service Offering, or a new CI record when on the Knowledge record. Again, user access is based on whether they pass one or more create/edit ACLs. This time however, as it is a dedicated table, it has its own ACLs which require the knowledge_admin role, but creation/edit of records also requires create/write access to the KB Article or CI as well, which is why it's better to suppress the "New" button and have use existing processes to create KB articles and CIs.