UFFA in ServiceNow

[Tommy SN Sahlin]

Hi KM Forum,

I would like for us together to share and define exactly how we implement and use the KCS basic UFFA flow in ServiceNow. For reference:

• How do you pragmatically make this work in the ServiceNow platform, step by step?
• What workarounds, configurations or customizations have you made to follow the UFFA workflow?
• What do your organizations work instructions look like, to achieve this in your ServiceNow platforms?

My hope is that if we collectively share our experiences, challenges, solutions, we can together realize and define how we should actually deliver this in our support organizations and ServiceNow platform solutions. The basis is:

1. Use it

For every incident, the support analyst shall perform a knowledge search.
If a knowledge article is found that resolves the issue, they shall always "use it", linking the article to the incident.

2. Flag it

If the support analyst finds errors in a knowledge article, sees room for improvement, or doesn't understand the content, they shall always "flag it" even if they can't update it themselves, explaining why they think improvements are needed. This shall generate a task for an appropriate SME group to create a new improved version of the article.

3. Fix it

If the support analyst finds a knowledge article with room for improvement as described above, knows what needs to be improved, and has the access rights to update the article, they shall always update the article right there and then.

4. Add it

If the support analyst does not find a knowledge article that resolves the issue, they shall always add a new knowledge article representing the identified knowledge gap. If they can develop the solution, they shall document and publish a new article. If not, the new knowledge article "embryo" shall be passed on to the appropriate SME group to document and publish a new article with the appropriate solution.

So, how do you pragmatically achieve these 4 points in ServiceNow in your implementations and organizations? I'm looking forward to your detailed responses! Please also specify your challenges, how you have technically achieved your goals, via plugins, configurations, customization, as well as via processes, best practices, work instructions etc. If as many as possible can contribute, I'll be happy to summarize our findings in a general article about ServiceNow UFFA best practices and how to achieve them.

cheers  /Tommy

[David Kay]

One quick update to your list: the Flag It or Fix It technique as described in the Practices Guide specifies you should only flag if you're not able to make the change yourself, generally because you're not licensed.  (The Practices Guide also says you can flag it if you're not confident in the change that's needed, but if you're not confident, why are you closing the case / incident?) So, most of the time, improvements are going to be straight edits...no flag necessary.

As an aside, I find the verb "fix" here problematic, since it implies that the article is somehow broken.  Most improvements are just that: generalizing the environment, adding symptomatology, capturing a different customer's context, or at worst updating the article to match the current release (in SaaS).  Rarely are you fixing something that is flat-out wrong.

As for how to implement it, the path ServiceNow has given us to implement the Solve Loop is pretty narrow and well defined: use the Knowledge Management Advanced and KCS plug-ins, modify Article templates as needed, modify Incident / Case fields and layout to provide Solve Loopers a place to capture the article as they're working.

Then, Solve Loopers search early, search often at the bottom of their Cases / Incidents and mark articles as helpful or a resolution to Reuse.  Flag or (usually) edit the article to Improve.

To Capture and Structure a new Article from a Case / Incident, keep notes in the appropriate fields you've added to your Case or Incident (e.g., "Symptoms or Question" "Applies To," etc.).  To actually create the article, it seems like there are two options: using the checkbox next to the Resolution field, or using the button approach documented on this page...uh, oh, the page wasn't updated after Orlando and it doesn't look like it's on the site anymore.  That's a problem!  And my PDI has been mysteriously down for the last couple of weeks, so I can't see how I did it.   But there's a way to make it so pressing a button causes a new article to be created, prepopulated from the case / incident using a field mapping you've defined.

ANYHOW, the bottom line is that the checkbox-next-to-resolution is super easy to implement, but doesn't give you as much flexibility to map fields from Case / Incident to new articles as the Button approach.

Looking forward to hearing from others!

[thomashansson]

In my PDI the flag and edit button is missing on the article when I open it from an incident. Is this OOTB behaviour? If so, how can ServiceNow be KCS verified without this solve loop functionality for improving articles in the workflow?

[Tommy SN Sahlin]

Yes, and the Flag button is also missing, we've had an Idea registered for this for a long time now. In our case at IKEA we have built it ourselves because it's necessary for UFFA. It is only ServiceNow CSM that is KCS certified, but that is usually not mentioned...

[Andreas Jansson]

Yes, this is how it looks OOTB and was also our reaction, how can this be KCS?
We ended up added the same Edit and Flag buttons so the UFFA flow could be applied.