
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
06-19-2023 10:45 AM - edited 07-30-2024 10:21 AM
Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field
Hi there,
Ever used the out-of-the-box Code Search, for example using Studio or SNUtils? And noticed that it will return a lot, though you might miss some artifacts? For example you will never find results regarding Email Scripts, or results regarding the message_html field of Notifications? That's correct, and... you can easily do something about it yourselves 😀
Let's have a closer look!
Code Search
Some customers might use a custom code search, which can be fine of course. Though out-of-the-box ServiceNow also has a nice Code Search functionality. I am noticing that this functionality is not that known by people in the ServiceNow eco-system while this is already out there for years, or people mentioning that the Code Search returns limited results.
What is the Code Search that I'm mentioning? Here is an example of Code Search within Studio:
And here the same Code Search, only then used by SNUtils:
You might come up with some more places in ServiceNow where Code Search can be used.
Code Search Tables and Fields
One of the nice things about the out-of-the-box Code Search from ServiceNow, is that the Tables and Fields included in searches are accessible for every admin and easily configurable! Basically the Tables and Fields are stored in table... "Code Search Table". Records contain the table name, and a comma-separated list of fields from that table to include in the search.
Good to mention, is that the records in the Code Search Table are associated with a parent "Code Search Group". Out-of-the-box there are two Code Search Groups: "sn_codesearch.Default Search Group" and "sn_devstudio.Studio Search Group".
The default search group for Studio is sn_devstudio.Studio Search Group. Looking at the Code Search Table records, you might notice that it only contains 21 records (tables) and that those records mainly contain search fields for the name, a condition, and a script. Did you know, that a fresh out-of-the-box Utah PDI contains 4,604 tables? There's way more to search than just these 21 tables! Another thought, why limit the search only to fields for the name, a condition, and a script? You could potentially search way more.
Expanding Code Search Tables and Fields
Unfortunately the default Code Search Group (and its Code Search Tables) for Studio cannot be edited because the application is Private. You can add new Code Search Tables though. Another option is creating your own custom Code Search Group and Code Search Tables. You could tweak this completely to your company, your desires on what to search for, or perhaps you also have custom tables and fields that you want to include in searches. While you could do so easily, doing such manually can be time-consuming. To expand Code Search for customers, I've created a script that can generate a new Code Search Group or expand an existing Code Search Group. In the script, I've added as much as possible script type fields, condition fields, etcetera. Basically it concerns Dictionary Entries for this encoded query:
internal_type.nameINhtml_script,condition,condition_string,script,script_client,script_plain,script_server,xml^ORelement=reference_qual^ORelement=calculation^nameNOT LIKEvar__m_^nameNOT LIKEsys_client_interaction^active=true^NQelementSTARTSWITHscript^ORelementLIKE_script^internal_type.nameSTARTSWITHstring^nameNOT LIKEvar__m_^nameNOT LIKEsys_client_interaction^active=true^NQname=sys_variable_value^element=value
Note: Currently the script only queries for Dictionary Entries in the global application scope only.
Pasting the code and maintaining it here is the most sustainable, so I've added the script to Share. From there I will update it if necessary, and everyone is able to download the script for free.
Only thing for you to do:
1) Decide if you want to expand an existing Code Search Group or create a new one. This can be done by editing the value on line 4.
2) Decide if the Dictionary entries listed suite your situation, or that you might want to add more or perhaps less. This can be done by editing the encoded query on line 5.
3) Run the Fix Script.
The script is set up in such a way that you can run it over and over. If after a while you for example have a new custom table or fields that should be included, just run the Fix Script again, it will only add new Tables and Fields, and it won't create duplicates (or at least it should not do so 😀).
Share
The Fix Script mentioned in this article can be downloaded from Share:
- Expand Code Search tables
Result
When running the Fix Script unchanged, a new Code Search Group should have been created which contains 286 Tables! Running a search using the new Code Search Group would take more time, simply because way more tables and fields are being searched for.
---
That's it. Hope you like it. If any questions or remarks, let me know!
C |
If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.
Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? |
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
4x ServiceNow Developer MVP
4x ServiceNow Community MVP
---
- 3,514 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Great topic! I personally always use the Application File [sys_metadata] table as a starter Code Search Table, which basically searches through all data captured in Update Sets. Very powerful 😎

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Nice article Mark,
This is indeed an underrated and unknown functionality which can really speed up development and debugging.
Always good to get more people informed about things like this!

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I used this script to add the tables and it worked great, but Code Search still isn't finding results in those tables, even after a cache.do. Is there something else I need to do to make it recognize the new tables? Thanks!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I have the same issue as Jennifer.
I changed the fix script to update the OOB search group "sn_devstudio.Studio Search Group" which does put a lot more tables in the select a table to search dropdown inside Studio, and does bring back a result from Widget Angular Provider, BUT only if I choose that table from the dropdown.
I'd expect my result to return if I leave the dropdown empty.
Edit: works fine using SN Utils
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@JenniferRah @Drew Carpenter There is a huge flaw with the OOTB code search: Only extending tables (the ones how have a sys_class_name) fields will be searched.
On top of that, the Studio Code Search will not display results of custom added tables because the "display list" is hardcoded.
In addition, flows will not be searched.
For this reason I have created my own Application, which includes code search and some other utilities (which need to be explicitly enabled):
https://github.com/kr4uzi/ServiceNow-DevOps-Plus
(checkout the Wiki for a feature preview)
My Code Search will search *all* application files (basically everything which creates an update xml record) by default so you don't even have to configure anything - including flow actions and form sections.