Hide 'scheduled for publish' workflow state of KBs from ESC even from kb writers

[ge3]

There is a KB workflow state Scheduled for Publish where we enter a future date on the KB before it sets the state the Published. I have an understanding that the criteria 'can contribute' or 'can read' can see these unpublished articles everywhere, but we want to hide it only in ESC. Right now it can be viewed by anyone who passes the criteria from the ESC. How do I do this without altering the criteria? I already have an open HI case and was pointed to some sys_properties but it does not work at this point. Any other thoughts?

[Matthew_13]

Hi my Friend,

 I believe your understanding is really correct and from what I’ve seen this is a known gap in how Knowledge visibility works with Employee service center.

From my experience, articles in Scheduled for Publish are still evaluated purely by the Can Read / Can Contribute criteria. If a user meets those criteria, the platform treats the article as readable, and ESC simply honors that. I don’t see an out-of-the-box way to hide scheduled articles only in ESC without changing the criteria themselves.

I’ve also found that the sys_properties often mentioned don’t really help here. They seem to control global Knowledge behavior like indexing or versioning, but not channel-specific visibility based on workflow state, which is what we actually need.

What I think works best, and stays upgrade-safe, is handling this at the ESC display layer instead of in Knowledge. In other words, filtering ESC so it only shows articles where the state is Published. That way, the Can Read / Can Contribute logic stays intact and we only change what ESC displays.

I also want to call out that indexing tweaks can help reduce visibility in search, but they don’t fully solve the problem, especially if someone has a direct link.

So overall, I don’t think there’s a clean sys_property solution today. From my perspective, ESC-level filtering is the safest approach, and anything else would either require customization or altering the criteria.

@ge3  - Please Mark Accepted Solution and Thumbs Up if you find Helpful!!

[ge3]

Hi, ESC level filtering is already set through search sources where Workflow = Published. Still it's showing the 'scheduled for publish' ones. Would this need a portal page script edit?

[Matthew_13]

Hi my Friend,

Good question — and no, not automatically. If your ESC search source is already filtered to Workflow = Published and you’re still seeing Scheduled for Publish articles, this usually means ESC is treating those records as published with a future date, not as a separate workflow state.

A couple of things to check before touching any portal or widget scripts:

1. Check the actual field values on one of the articles
Open one of the Scheduled for Publish articles that is showing and look at:

• workflow_state

• valid_from / publish date

• valid_to (if used)

In many setups, the workflow state is already published, and the scheduling is controlled only by the publish date. In that case, Workflow = Published alone will still return the record.

2. Add a time-based condition to the search source
Instead of filtering only on workflow, add a date constraint so future-dated articles are excluded, for example:

• workflow_state = published

• AND valid_from <= now

• AND (valid_to is empty OR valid_to >= now)

This is usually enough to stop scheduled articles from appearing and keeps everything upgrade-safe.

3. Confirm where the articles are appearing
Search source filters only apply to search results. If the articles are showing up in:

• category browsing

• recommended / popular content

• related knowledge sections

then they’re coming from a different ESC component, not the search source.

Only if the articles are coming from one of those widgets and you cant express the filter there would you need to clone the widget and add the same “published + date” condition in the server-side query. Editing portal page scripts directly should be the last resort.

Basically : try the publish date filter first. Most of the time that resolves it without any portal or widget customization.

[ge3]

I've added a couple of lines and these criteria is very straight forward but nothing really appears to be changing. This is just searching in ESC using KB number. This page above is in ais_search_source