Finding information in CRM is HARD.
For those who were lucky enough through the years of dial-up modems and MySpace, you’ll recall what it was like to discover new things on the internet. Sure, companies like Yahoo aggregated and organized content from around the web, making it easy to navigate and drill down to the content you wanted like this: Sports >> Baskteball >> College >> Division1. And sure, they had a text box you could type a keyword into that would bring back results.
But then Google came along and showed us what Search was always meant to be about:
- Universal: all of a sudden, you could search the ENTIRE web, not just content that was syndicated and aggregated
- Unstructured: you could type in any keyword and still get relevant results… you weren’t limited to one part of the site
- Filterable: you could refine your search results by different types of object (images, news, etc)
- Fast: you could get results in milliseconds… so much faster than any report you run in SFDC today
If you’ve used Salesforce’s search functionality, you probably agree that it falls short on all these dimensions.
BUT we have some good news… it doesn’t have to be that way. In this article, we’ll share how you can customize Salesforce Search in less than 30 minutes to get Google like performance and results.
First, A Little Background
Most people know that Salesforce is built on a relational database, which allows you to create objects (tables), create columns (fields), create relationships (lookups), and build reports that look like what you’d get in an excel spreadsheet. They also understand the idea of being able to add filters that let you query the data with operators like “CONTAINS”.
So when they think about Search, they think about running a “CONTAINS” query across their entire dataset. But this concept doesn’t actually work with search for a few reasons:
- CONTAINS queries are slow (and impossibly slow when running against every row/column). And as we know, Search needs to be FAST.
- CONTAINS queries are limited to specific tables. And as we know, Search needs to be GLOBAL
- CONTAINS queries look for exact matches. As we know, Search needs to disambiguate and understand what you actually WANT.
This is why Google invented a new type of database technology (appropriately called a “Search Database”) which is specifically built to solve search problems. And just like all things in life, it comes with tradeoffs that make it really bad at what a relational database does, but really good at creating a great search experience.
Salesforce’s search experience is powered by this exact technology, making it a very powerful tool when used right.
How Does Salesforce Search Work Out of The Box?
Salesforce has a process that runs roughly every couple minutes and ingests all of the changes to the core database and pushes it into its Search database cache. This means there is a small latency from the time an object is created/updated until that data becomes searchable.
Once in the database cache, your searches execute against this cache and return results based on EXACT keyword matches. Note: while Salesforce doesn’t apply intelligence on queries the way Google/Facebook do (eg: “Show me tasks related to the ACME account last month”), it has rolled that capability out in Beta under the name “Einstein Search” and you can turn it on for your instance if that’s interest.
Once you get search results, Salesforce allows you to filter the results by object. And once you select an object, it gives you a set of predefined filtering options in the search panel that helps you further refine your search.
What few people know about SFDC search is that you have some really powerful customization options around these filters
- you can have up to 10 of them active in the Search experience
- you can customize them by object
- you can customize them by User Role.
More on that later…
Technical Limitations of The Default Search Configuration
As you’ve probably inferred, Salesforce’s default configuration has a number of limitations:
- No global search: only frequently used objects populate in the default search results page. This means users have to click into all of the infrequently used objects one by one for every. single. query. to make sure there actually are no results. Yuck.
- No cross-object filters: search filters are limited to fields on the object. This means you can’t filter a search for “Demo Calls” by the Opportunity stage of the deal. Gurh.
- Filters only support TEXT and PICKLIST fields: for example numbers are not supported (eg: you can’t filter by “calls over 5 minutes”). Yeesh.
But fortunately… it doesn’t have to be that way.
How To Fix These Limitations
While we can’t change how Salesforce queries and presents the data, we can change the data structure that the search engine is ingesting so that you can get better search results, better filters and a truly unified search experience.
The first step is to recognize that Salesforce’s global search only works on frequently used objects in Salesforce Lightning. This means that we want to make sure whatever data we want to make searchable, we want to focus the search experience on those objects where possible.
The second step is to think about how we can consolidate this data into those objects through some kind of data transformation (triggers, process builders, flows, etc). You’ll also need to consider whether the data you’re copying across objects are a ‘snapshot’ value or need to be kept up to date. For example, if you want to filter demo calls by opportunity stage at the time of the call, you’ll need to store a ‘snapshot’ value of the opportunity. If you want to filter for calls based on the current stage of the opportunity (eg: show me demo calls that ended up leading to closed/won), you’ll need to store a value that is constantly updated when then opportunity stage changes.
The third step is to recognize that we need to translate the data we want to query/filter into a field type of TEXT/PICKLIST. This can be achieved easily through fields that update via formula or process-builder/APEX code . For example, if you want to filter by call duration, you’ll want to translate callDurationSeconds into a picklist like “1-2 mins”, “3-5 mins”, etc.
The fourth step is to consider how you want to customize the search experience across users. The process of actually doing this is actually very simple:
- Navigate to Salesforce Admin >> Object Manager >> Select The Object
- Click on Search Layouts
- Click on the User Profile
- Select the relevant search results filters
- When you navigate to the Salesforce Search results page, do a hard refresh (Control + Shift + R). Since Salesforce caches pages to make things run faster, this will ensure it pulls down the latest updates immediately
How To Fix These Limitations in 20 Mins
The steps above require both experience in modeling data and building out scalable processes in Salesforce using Process Builder, Flows or APEX; probably a 15 hour job with additional maintenance.
You may be wondering… “is there an app that will just do this for me?”
Fortunately, we have a FREE app for that :)
Here’s why you might want to consider using it:
- Written entirely in APEX: so it’s extremely efficient with system resources, non-blocking and is a one click install/uninstall
- Works out of the box: it’s designed to work with many of Salesforce’s native fields and will allow you to search for Activities in a whole new way without any config. For example, you can filter tasks by CallDurationSeconds right out of the gate.
- Highly Configurable: we’ve implemented a custom object architecture which lets you add up to 800 custom fields to your activity data. This means limitless customization in both your search experience, and in reporting.
- No-Code Data Transformations: you can do all of the data transformations mentioned above from a single text file (no process builders or APEX coding required)
Where can I get this App?
Just head on over to this page! And if you need help, don’t hesitate to hit the ‘chat’ button to start a conversation with our sales team.
