Inconsistency in Knowledge Article Workflow Field After Upgrade

George_1
Giga Guru

3 weeks ago

I’ve noticed an inconsistency in the Knowledge Article workflow field after recent upgrade. When opening a new article form, the workflow sometimes shows as “Pending – Not Yet Started” instead of the expected “Draft.”

Has anyone else experienced this behavior?

 

George_1_0-1780680210645.png

 

0 Helpfuls
  • 1,346 Views
8 REPLIES 8

PushpankD
Tera Contributor
In response to Pratik Yadav1

Friday

Few observations --

1. I used standard template i see the issue

2. Same is working for other template (from EA)

3. Its working fine in Dev but UAT i see the issue.

4. Knowledge Center where its show issues in workflow life cycle as  mentioned by xostmoen

 

0 Helpfuls

xostmoen
Kilo Sage
In response to PushpankD

Friday

I did get a response from SN support, it seems like our issue will be fixed in Australia Patch 3.

Although we also where provided with a workaround, I have not tried this out yet, and will probably apply the permanent fix instead at a later time.

 

This is what SN support statet:

 

Cause

This is a known product defect (PRB1980077/PRB2009991) introduced in the Australia release. The WorkflowStageProcessor Script Include retrieves a cached ChoiceList object and passes it to WorkflowIcons.process(), where the choice labels get modified in place. Because the cached object itself is being mutated, subsequent reads return incorrect labels like "Pending - has not started" instead of the actual workflow state values such as "Published" or "Draft." Admin users are not affected because their sessions resolve the field value through a different path.

Solution Proposed
A permanent fix for this issue is included in Australia Patch 3, which is expected to release soon. The fix deep-clones the ChoiceList before mutation so that the cached copy is never corrupted.

If you need a resolution before Patch 3 is available, the workaround is suggested in KB3090094

Workaround
1. Navigate to sys_script_include_list.do
2. Search for: WorkflowStageProcessor
3. Open the script include and locate the getChoiceList() method
4. Inside the default: case block, update the code as follows:

Before:

var clGenerator = new GlideChoiceListGenerator(this.tableName, this.fieldName);
clGenerator.none = false;
choiceList = clGenerator.get();

After:

var clGenerator = new GlideChoiceListGenerator(this.tableName, this.fieldName);
clGenerator.none = false;
clGenerator.setCache(false); // Prevents cache poisoning
choiceList = clGenerator.get();

5. Save the record
6. Flush cache on all nodes using one of the following methods:
- Navigate to cache.do on each node
- OR run gs.cacheFlush() from a background script to flush all nodes at once

If you are still seeing the issue after the above steps, run the following from a background script to clear the table-specific cache:

GlideCacheManager.prefixFlush('sys_choice_compiled', 'kb_knowledge');

Performance Impact
Minor. Workflow choice lists will no longer be cached, but the impact is expected to be negligible for most instances.

The permanent fix is available in Australia Patch 3. The permanent fix deep-clones the ChoiceList before mutation so the cached copy is never corrupted.

 

dhoang22
Tera Contributor
In response to xostmoen

Friday

This solution is also what I get from ServiceNow HI. The fix worked for the native view, but the issue is still occurring in Service Operations Workspace. We've reached out to ServiceNow and are waiting for their feedback.

0 Helpfuls

mza-guille
Mega Contributor

Sunday

Hi George,

I would treat this as two separate questions before changing any workflow configuration:

1. Is the Knowledge record actually in the wrong workflow state?
2. Or is the UI displaying the workflow/stage label incorrectly after the upgrade?

The reason I would separate those is that another reply mentioned Australia Patch 2 and that the stored workflow state appears correct while the displayed stage shows “Not Yet Started”. If the stored value is correct, then changing Knowledge workflow/business logic may make the problem worse.

I would check these items first:

  • On the affected article, verify the actual stored value of workflow_state on the Knowledge record.
  • Compare Classic UI and Workspace behavior for the same article.
  • Test with a brand-new article and with an existing article/new version.
  • Confirm which Knowledge workflow is attached to the Knowledge Base.
  • Check whether the article has an active workflow/context running, not only the display label.
  • Try cache/browser cleanup, but do not stop there if multiple users/browsers reproduce it.

If the database value is Draft but the UI says Pending / Not Yet Started, that points more toward a display/UI/regression issue after upgrade. In that case, I would open a ServiceNow Support case and provide:

  • exact family/patch version,
  • affected Knowledge Base,
  • screenshot from Classic UI and Workspace,
  • actual workflow_state value,
  • whether it happens only on new articles or also existing/new versions,
  • whether the workflow context is active/completed.

If the database value itself is being set incorrectly, then I would review custom Business Rules, UI Actions, flows/workflows, and Knowledge Base workflow configuration.

So I would not recommend changing scripts until you prove whether this is data-state wrong or display-state wrong. That distinction is the important part here.

0 Helpfuls