Attach Knowledge Articles to a Service Offering

[Michele O_Dell]

On a service offering, there is a Knowledge Article tab. I would love to attach knowledge articles to the offering that provide support information, how tos, and etc related to the offering. What role is required to expose a New button on that tab so we can related KB articles to the service? I even had the person with the Knowledge Base ownership/admin role try and she doesn't get a new button. We even looked at KB articles to see if the association can be done from that end. No luck. Any suggestions? Also, I cannot find answers to any of these questions in the documentation!

[Ravi Chandra_K]

Hello @Michele O_Dell 

Hello @Michele O_Dell 

Check ACLs and Query BRs on the kb_knowledge table.

Or there might be restriction at the related list level it self.

(Go to configure -> Related list -> and check the conditions at the related list.

Please mark this answer as helpful and correct if helped.

Kind Regards,

Ravi Chandra.

[Tai Vu]

Hi @Michele O_Dell 

Are you talking about the OOTB Knowledge Articles related list? If yes, you can look into the Relationship [sys_relationship] table to see the query inside. It's most probably associated with the Configuration Item field on the Article record.

Cheers,

Tai Vu

[Mathew Hillyard]

Hi @Michele O_Dell ,

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.

Hope this helps!