Salesforce Lightning Global Search in Chrome URL Address Bar
Google Chrome has a great feature that allows users to map a query (typically a search key term) in websites other than google. The prerequisite is that these websites accept a key term that is plain-text in the URL for the website to return the search results. Back in Salesforce classic this worked flawlessly and the URL would have looked something like the following (provided that the user has a valid session id):
https://test-dev-ed.my.salesforce.com/_ui/search/ui/UnifiedSearchResults?str=Test&searchAll=true
This classic URL accepted many configuration parameters like ViewMode (Summary or Detail), specific sObjects to search for, searchAll (Display all sObjects immediately without having to expand the list), etc. To configure the chrome search engine for a classic search is super easy. Go to Chrome Settings → Search Engine → Manage Search Engines → Add.
Add a name and a keyword (the keyword is used every time you want to invoke the search engine in the address bar). For the URL you would just add the following (changing your Salesforce domain):
https://test-dev-ed.my.salesforce.com/_ui/search/ui/UnifiedSearchResults?str=%s&searchAll=true
Notice I just switched the search term with %s which is what the browser uses to merge in the string you pass it in the search engine. Then go to the address bar, type your keyword and space, then you type your search term. Works like a charm !
But then, Lightning came along. We saw that the URL still changes on each search, but the content of all these parameters were base64 encoded. This is done likely for security reasons (i.e. automated processes that parse the URLs). There was no straight forward way to URL hack this search anymore. If we base64 decode whatever it is the URL has, we get a better idea of what Salesforce is doing with the Search in the URL.
If you look at the actual information that is being passed along you can see a term attribute (this is where we will use the %s merge notation for the search engine). You also can see a searchDialogSessionId which is a UUID that identifies the session id of the dialog (after testing in both Summer 19 and Winter 20 I realized this is not being used in the way I was expecting — I got away with passing all 0’s). So, as long as you can base64 encode this structure and merge the search engine query in the term field, then you can redirect to the Salesforce Global Search results for that specific term. Here is where JavaScript comes into play. Leveraging JavaScript we can run these operations on the string after google merges the query string and redirect.
Here is the URL you need for the Search engine. Notice %s is already where it should be placed for the search engine to merge into the script, just replace the base lightning domain for your own and that is it:
All the options selected in the script were added with those values because it is what Salesforce had set for my search tested internally in the ORG. You can expand on this and play with different configurations to suit your need.
Final result you can see in this video:
One final note, Chrome does not allow JavaScript to be ran in the NewTab page. My solution was to have a redirect immediately in the NewTab which takes me to Google directly every time (chrome extension here). This makes it so I never have issues whenever I decide to search among all my Salesforce environments in the Search Bar. Each Salesforce environment will require its own Search Engine Definition.
