Public Portal

[ttmathew]

We are on the verge of introducing Public Portal for our external customers, however we realised that the OOB doesn't have the feature to create KFT's for feedback or reason pop up on the Public portal. I am reachign out to the community to seek opinion on what are the ways we can have this enabled to capoture feedback on the Public Portal through KFT from ur external customers. 

[musislam]

Hi ttmathew,

My guess is this comes down to the guest user. The feedback pop-up and the feedback task creation assume someone is logged in, and on a public page the request runs as guest, which the knowledge base blocks from contributing by default. So nothing gets written to kb_feedback and no task is created.

The options I've seen are to ask users to log in before they give feedback, which is the simplest and safest, or to build a small public widget that saves the feedback on the server side with some spam protection. I'd stay away from opening the feedback tables up to guest.

To point you the right way:

1. Which portal is this, the CSM public portal or your own public Service Portal, and which release?

2. Are your external customers anonymous, or are they CSM contacts who could log in?

3. Does the knowledge team need to know who left the feedback so they can follow up?

If that works for you, mind marking it as the recommended solution? Helps me support these better for the community.

[ttmathew]

Thanks for your response, just to clarify, when I refer to external customers, I’m referring to members of the outside public who are anonymous users and do not have access or login credentials to our environement or ServiceNow.

We are planning to launch our Public Portal shortly, and one of the key outcomes is to provide a public-facing knowledge base that can be accessed by the external audience without authentication.

For example, the knowledge base would provide information on topics such as: guest Wi-Fi, temporary and visitor parking, visitor information, campus environment and facilities, other general information relevant to members of the public We are currently on the latest ServiceNow release. Let me know if this information helps..

[musislam]

Hi @ttmathew

That helps, thanks. Fully anonymous rules out the login option, so you are into a custom build for this one.

Two things are in the way. First, on the knowledge base form there are two related lists that are not on the form by default, Cannot Read and Cannot Contribute, and both exclude the Guest user out of the box. Clear Guest out of those or the public KB will not behave no matter what else you set. Second, the OOB feedback pop-up tries to write to kb_feedback as guest, and guest has no create access there, so nothing lands and no KFT is raised.

Rather than open kb_feedback up to guest, I would put a small public widget under the article, a simple was this helpful with an optional comment and an optional email address. Mark the page public on the sp_page record and the widget public on the widget record, then do the insert in the widget server script. Server side GlideRecord does not evaluate ACLs, so you can write the kb_feedback record without giving the guest user create rights on the table. Once that record exists the OOB business rule Knowledge Feedback Task Creation still fires and you get a real KFT, so your knowledge team keeps the process they already have.

(function() {
  if (input && input.action == 'feedback') {
    var fb = new GlideRecord('kb_feedback');
    fb.initialize();
    fb.article = input.article;
    fb.comments = input.comments;
    fb.flagged = input.is_flag ? true : false;
    fb.insert();
    data.saved = true;
  }
})();

Worth sanity checking the field names on kb_feedback in your instance before you wire that up, they vary a bit by release.

Two things to watch. The submitter is guest so there is no one to follow up with, which is why I would add the optional email field if your knowledge team needs to close the loop. And it is a public form, so you own the spam problem, the OOB reCAPTCHA properties only cover external user self registration, so you will need your own captcha and some basic rate limiting.

Also, do not flip kb_view itself to public. Clone it for the public KB, otherwise unauthenticated users hitting a restricted article get a privileges error instead of a login prompt.

If that works for you, mind marking it as the recommended solution? Helps me support these better for the community.