Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

How to index sn_ex_sp_quick_link so Available For related list is respected by the search, or what t

Nick39
Tera Contributor

Is there is a way to have the search result behave the same as the KB articles?

When we create quick links in ECPro they are created in the sn_ex_sp_quick_link table.

 

When a quick link record is opened, there are several related lists at the bottom.

The 2 related lists, the Assigned Topic and Available For (see attachment), how do they work?

 

external.link.png

 


Further investigation revealed that the quick link's Available For related list is using sn_ex_sp_quick_link_user_criteria_mtom table.
Since this is M2M table is this ok? Can we assume the search is able to see this and respect the permission. Could it be the way indexed source is set up?

2 REPLIES 2

Vishal Jaswal
Tera Sage

Hello @Nick39 

Table: sys_ui_list_control is where you can find "Assigned Topics" being configured as Related List for Quick Links table "sn_ex_sp_quick_link"

VishalJaswal_1-1790117359165.png

Available for is the user criteria i.e. to make the Quick Link Available for specific person or roles or groups etc. This Available for can be removed by Configure > Related List 

VishalJaswal_2-1790117478212.png

 

VishalJaswal_3-1790117488301.png

 




Hope that helps!

We're looking for the Available For related list to control who can see the quick link. We had also opened a support ticket and this was the response via AA, but looks to align to what we were looking for:

 

"Issue:
You asked how quick links in Employee Center Pro should be indexed so search respects the Available For related list, whether sn_ex_sp_quick_link_user_criteria_mtom is the correct relationship table, and whether search should behave like knowledge articles for permission filtering.

Business Impact:
If search does not honor the quick link access criteria, users may see links that should not be visible to them, which can cause confusion and expose content outside the intended audience.

Steps to Reproduce:

  1. Create or open a quick link in Employee Center Pro.
  2. Review the Assigned Topics and Available For related lists on the quick link.
  3. Configure user criteria in Available For.
  4. Run search as a user who should not match that criteria and compare the result visibility.

 

Most Probable Cause:
The Available For related list is the supported mechanism for restricting quick links through user criteria, and the M2M table is expected for that relationship. If search is not respecting those restrictions, the more likely cause is access control behavior on the quick link table rather than the fact that the relationship is stored in an M2M table or that the M2M table itself is not indexed.

Solution Proposed:

  1. Use Assigned Topics only to place the quick link in Employee Center or Employee Center Pro navigation and topic content. This related list controls where the quick link appears, not search permission enforcement.
  2. Use Available For to add or update the user criteria that restrict who can access the quick link. The relationship through sn_ex_sp_quick_link_user_criteria_mtom is expected and supported for quick links.
  3. If users who do not meet the Available For criteria can still find the quick link in search, review any custom read ACLs on sn_ex_sp_quick_link before changing the indexed source. A similar resolved case found that broader custom read access caused search visibility to ignore the intended quick-link restrictions.
  4. Keep sn_ex_sp_quick_link as the indexed source table when the goal is to make quick links searchable. The M2M table stores supporting permission relationships and is not the table that should be indexed for search results. After any ACL correction, reindex the quick link source if needed.

 

Next Steps:

  1. Please review the quick link's Available For user criteria and confirm they match the intended audience.
  2. If the issue continues, review custom read ACLs on sn_ex_sp_quick_link and then reindex the quick link source.
  3. If this resolves the behavior, you can accept the solution on the case. If not, reply to this case with the ACL findings and the affected search behavior.

 

***

Best regards,
ServiceNow AI

References:

Just adding this here if this could help out anyone else.