We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Inconsistency in Knowledge Article Workflow Field After Upgrade

George_1
Tera Guru

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

 

10 REPLIES 10

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

 

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.

 

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.

@dhoang22 @xostmoen @George_1  What is the solution provided by servicenow for workspace view. can u please help me with this we also facing the same issue the solution works in Native view but not in Workspace view

We have upgraded to AUS patch 3 even the issue is not fixed, also i have updated the script include as mentioned but could not see any changes, kindly help on this to proceed.