Enable 'Related Items' at question level for non Record Producer catalog.

katrina777
Kilo Explorer

11 hours ago

Greetings all,

 

We want to implement a deflection to an existing general group access catch all catalog at question level where the Related Items suggestions are displayed as the user types in the access group they seek. 

 

We are aware this option is possible in a record producer catalog - but we want to implement it for a catalog item.

Does anyone have information on how we can successfully add the Related Items suggestions to a question in a catalog?

0 Helpfuls
  • 126 Views
1 REPLY 1

Vikram Reddy
Giga Guru

5 hours ago

Hi @katrina777 ,

 

What you are describing is the platform's Contextual Search feature, sometimes called "related search results" or "related items" by admins because that is what it visually produces: a live panel of suggestions under a field as the user types. It is not something separate that only exists on Record Producers, it is just that the out-of-box configuration table for it, Record Producer Configuration (table name cxs_rp_config), has its "Record Producer" reference field scoped to the Record Producer table only. That is a dictionary/reference-qualifier restriction, not a hard architectural limit, and it is worth understanding why before you touch anything.

Why it works this way


A Record Producer (sc_cat_item_producer) is a class that extends Catalog Item (sc_cat_item) in the table hierarchy. The "Record Producer" field on cxs_rp_config is actually a reference into sc_cat_item under the hood (that is why its column name is literally sc_cat_item), it is just filtered by dictionary/reference qualifier to only show rows of the Record Producer extension. So the underlying data model already supports pointing this config at any catalog item, ServiceNow simply never opened that field up in the UI for plain catalog items.

 

How Contextual Search is normally wired on a Record Producer, for reference:

  1. On the variable you want to type suggestions against, set the variable type to Custom (or a text type with a widget override) and set the widget/macro to Contextual Search - Inline Results (macro cxs_rp_search) under Type Specifications.
  2. Navigate to Contextual Search > Record Producer Configuration and create a new record: pick the Record Producer, the Search Variable (the variable from step 1), and the Search Context that defines which search sources feed the suggestions (Knowledge, Catalog, or a custom source you've built).
  3. Only one variable per producer can be wired to contextual search this way, so pick the field the deflection actually hinges on (in your case, the access group / group name field).

Extending it to a plain catalog item:

  1. Go to cxs_rp_config_list.do, right-click the "Record Producer" column header, and choose Configure Dictionary.
  2. In the Reference Specification section, change the Reference from Record Producer to Catalog Item [sc_cat_item] (you can relabel the field if you want it to read cleanly for your team).
  3. Create the Record Producer Configuration record against your general access catalog item, choosing the text variable that captures what the user types as the Search Variable, and the same Search Context you'd use on a producer.
  4. On that variable, set the widget/macro exactly as above (Contextual Search - Inline Results / cxs_rp_search) so it actually renders the inline results panel on the catalog item's variable editor, both on the classic UI and in Service Portal/Employee Center.

Keep the below the points before you finallize the code:

  • This is a dictionary override on a platform table the Contextual Search plugin owns, not a documented, supported configuration path. Treat it like any other OOB customization: put it behind an update set, note it clearly for whoever does the next upgrade, and re-test after upgrades since ServiceNow could tighten that reference qualifier in a future release.
  • Confirm your Search Context and Search Sources actually cover what you want surfaced (group records, a knowledge base of access groups, or whatever table backs your catalog) before wiring the variable, the panel is only as good as the source it's pointed at.
  • If suggestions render in the platform UI but not in Service Portal, check the Angular template cxs-result-catalog in sp_ng_template, there are known cases where the "Order"/selection action needs a small markup tweak to show correctly on portal-rendered catalog items.
  • Since only one variable per config record supports contextual search, if the access group field isn't first on the form, make sure your catalog UI policies don't hide or reorder it in a way that breaks the typeahead binding.

I've implemented this exact workaround for a client who needed "type-ahead to group/queue" deflection on a general-purpose access request item rather than a producer, and it held up fine across two release upgrades once it was captured in an update set with a note on the dictionary override.

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls