How can we configure AI Search to Redirect Software Name Results to a Static Catalog Item

[YaswanthKurre]

How can we configure AI Search on the Service Portal so that when a user searches for a term matching a record in a custom software list table (software names), the search results return and redirect the user to a single static catalog item?

[MaryG · Accepted solution]

Thanks for the detailed follow-up @Yaswanth — good questions. Let me take them in order.

**On synonyms and KB impact**
AI Search synonyms are scoped to the Search Profile they're configured in, so the blast radius is controllable. If you add software name synonyms at the profile level and your KB articles are in the same profile, broader matches are possible — but it's low risk and fully reversible. To keep it clean, scope synonyms to the catalog search context specifically if your portal has separate search contexts configured.

**On overriding the result URL (Option 2)**
In the Search Source record, there's a Result URL field where you can define a static or templated URL. You can reference indexed field values using ${field_name} syntax, so something like:
/sp?id=sc_cat_item&sys_id=YOUR_CATALOG_ITEM_SYS_ID&sysparm_software_name=${name}

Known limitations to be aware of:
- Pre-population only works if the catalog item variable is configured to accept URL parameters (the variable name in the URL must match the catalog item variable name exactly)
- Test this in your portal before committing — SP catalog item URL parameter behavior can be inconsistent depending on how variables are configured
- The result card in AI Search will still display the custom table record's fields, so you'll want to configure the display fields in the Search Source to make the result look intentional to the user

**On avoiding the custom formatter**
Yes — skip it for this use case. It's the right tool when you need to control result rendering or click behavior across a source broadly, but it introduces scope and maintenance overhead that isn't justified here.

**Recommended path given your setup**
Start with Option 1. Configure the Software Request catalog item with software names as search keywords (on the catalog item record itself, or via AI Search synonyms). Test whether search surfaces the catalog item reliably for your top software names. This is the lowest-effort, most maintainable solution and doesn't require indexing the custom table at all.

Only move to Option 2 if you have a large, frequently updated software list that makes synonym maintenance impractical — at that point the custom table as a source with a configured Result URL becomes worth the setup effort.

[MaryG]

There's no native redirect behavior in AI Search — results open whatever URL the search source is configured to point to. So the approach depends on where you want to build the logic.

Here are three paths, roughly in order of complexity:

**Option 1: Configure the catalog item as the search source (simplest)**
If the goal is to always land users on a single catalog item, the most direct path is making that catalog item highly discoverable rather than indexing the custom software table at all. Add your software names as synonyms or keywords in AI Search configuration (Search Synonyms, or the catalog item's search keywords field) so that searching "Adobe Photoshop" surfaces the Software Request catalog item directly. No custom table involvement needed.

**Option 2: Custom table as search source with a modified result URL**
If you do want to index the custom software table, you can add it as an AI Search source and customize the result URL in the Search Source configuration to point to the catalog item page instead of the record. You can append query parameters to pre-populate a catalog item variable (e.g. the software name) so the user lands on the right item with context. This requires some configuration work and testing across Portal search behavior.

**Option 3: Search Result Formatter (most flexible, most work)**
For full control over result rendering and click behavior in Service Portal, a custom Search Result Formatter widget lets you intercept the result and control where the link goes. This is the right path if Options 1 and 2 don't give you enough control, but it's a development effort.

What's your current setup — are you already indexing the custom software table as a search source, or starting from scratch?

[YaswanthKurre]

Hi @MaryG ,

Thank you for your response.

Option 1: Option 1: Configure the catalog item as the search source (simplest)**
If the goal is to always land users on a single catalog item, the most direct path is making that catalog item highly discoverable rather than indexing the custom software table at all. Add your software names as synonyms or keywords in AI Search configuration (Search Synonyms, or the catalog item's search keywords field) so that searching "Adobe Photoshop" surfaces the Software Request catalog item directly. No custom table involvement needed.

--

Will adding software names as AI Search synonyms to surface a single catalog item impact Knowledge article search results or the overall portal search behavior?

--

Option 2: Custom table as search source with a modified result URL**
If you do want to index the custom software table, you can add it as an AI Search source and customize the result URL in the Search Source configuration to point to the catalog item page instead of the record. You can append query parameters to pre-populate a catalog item variable (e.g. the software name) so the user lands on the right item with context. This requires some configuration work and testing across Portal search behavior.

--

When indexing a custom software table as an AI Search source, what is the recommended approach to override the result URL to point to a catalog item (with query parameters for variable pre‑population), and what are the known limitations or portal search considerations?

--

Option 3: Search Result Formatter (most flexible, most work)**
For full control over result rendering and click behavior in Service Portal, a custom Search Result Formatter widget lets you intercept the result and control where the link goes. This is the right path if Options 1 and 2 don't give you enough control, but it's a development effort.

--

Given that a custom AI Search formatter would alter search behavior across all results and introduce long‑term maintenance complexity, is it recommended to avoid this approach in favor of more out‑of‑box, easily reversible options?

--

What's your current setup — are you already indexing the custom software table as a search source, or starting from scratch? 

--

We already have AI Search configured, but the custom table is not indexed. Since we’re starting from scratch, what is the best option to explore?

--

Once again thank you Mary.

Thanks,

Yaswanth.

[MaryG · Accepted solution]

Thanks for the detailed follow-up @Yaswanth — good questions. Let me take them in order.

**On synonyms and KB impact**
AI Search synonyms are scoped to the Search Profile they're configured in, so the blast radius is controllable. If you add software name synonyms at the profile level and your KB articles are in the same profile, broader matches are possible — but it's low risk and fully reversible. To keep it clean, scope synonyms to the catalog search context specifically if your portal has separate search contexts configured.

**On overriding the result URL (Option 2)**
In the Search Source record, there's a Result URL field where you can define a static or templated URL. You can reference indexed field values using ${field_name} syntax, so something like:
/sp?id=sc_cat_item&sys_id=YOUR_CATALOG_ITEM_SYS_ID&sysparm_software_name=${name}

Known limitations to be aware of:
- Pre-population only works if the catalog item variable is configured to accept URL parameters (the variable name in the URL must match the catalog item variable name exactly)
- Test this in your portal before committing — SP catalog item URL parameter behavior can be inconsistent depending on how variables are configured
- The result card in AI Search will still display the custom table record's fields, so you'll want to configure the display fields in the Search Source to make the result look intentional to the user

**On avoiding the custom formatter**
Yes — skip it for this use case. It's the right tool when you need to control result rendering or click behavior across a source broadly, but it introduces scope and maintenance overhead that isn't justified here.

**Recommended path given your setup**
Start with Option 1. Configure the Software Request catalog item with software names as search keywords (on the catalog item record itself, or via AI Search synonyms). Test whether search surfaces the catalog item reliably for your top software names. This is the lowest-effort, most maintainable solution and doesn't require indexing the custom table at all.

Only move to Option 2 if you have a large, frequently updated software list that makes synonym maintenance impractical — at that point the custom table as a source with a configured Result URL becomes worth the setup effort.

[YaswanthKurre · Accepted solution]

HI @MaryG ,

Thank you for your inputs.

Summary of approaches evaluated:

• Option 1 (Exact match / synonym‑based search)

  • This option works correctly from a functional perspective.
  • However, it requires the software name to be an exact match to act as a synonym.
  • Many of our software names contain numbers and special characters (e.g., hyphens).
  • End users typically do not search using exact names, numbers, or special characters.
  • As a result, this approach often does not return relevant results, making it less effective for our use case.

• Option 2 (Redirect users to a target URL such as a catalog item)

  • This is the most suitable and user‑friendly approach for our requirement.
  • However, in our instance, there is no “Result URL” field available on the Search Source configuration, which limits the standard OOB approach.

Implemented solution (custom but controlled):

• We created a Custom Action Assignment with a Custom Action Payload Definition. 

{
  "url": "{{u_url}}"
}

• Added a URL field (u_url) on our custom software table.
  • Field type is URL.
  • The value is dynamically populated based on our internal logic and software‑to‑catalog mapping.
• Configured AI Search Results Configuration to:
  • Use our custom search source
  • Trigger the custom action for navigation
• Implemented an EVAM View Configuration and EVAM View Template for our custom table to ensure:
  
  • Proper accessibility mappings (cardLabel, buttonLabel, etc.)
  • Navigation behavior aligned with the custom action

Thank you for your approaches on this.

Regards,

Yaswanth