How to implement a custom search in Salesforce Lightning

LWCLeave a Comment on How to implement a custom search in Salesforce Lightning

How to implement a custom search in Salesforce Lightning

The Global Seach Box – as illustrated before – is quite limited when it comes to search options. During a previous project, I noticed the search process could be optimized a lot by for example implementing a default landing page as which Pablo defined the UX with his own search options instead of using the Global Search Box.

In this blog post, I’ll be talking about what we need to create a custom search in, for example, Service or Sales Cloud. While implementing a custom search, different choices have to be made and with that, different tools have to be chosen. We focused on 5 things:
1. Organizing a sandbox
2. Installation of VS Code and retrieving the Force app
3. Creating a custom search in VS Code
4. Deploying the Custom Search to the sandbox
5. Organizing the Console App

1. Setting up a sandbox

First, a sandbox environment needs to be created in which we can develop. This environment will also have to contain data to search through. For this, we set up REST Services that integrate with our Subscription Domain and made sure we generated subscriptions from LeadQ accounts. These sandboxes can be created via Setup → Sandboxes. Of course, these sandboxes also have their limitations when it comes to data. For example, production data can’t be shown 1 on 1. Reason? The general program’s logic is copied to the sandbox, so there’s not much we can do about it, unfortunately.

2. Installation of VS Code and retrieving the Force app

After creating the sandbox, we needed to install VS code and retrieve the Force app. We could also develop from within the browser, but the Developer Console doesn’t support creating LWC (Lightning Web Components); this can only be done from within VS Code. As the installation of this VS Code is a topic in itself, we discussed this in one of the earlier posts written by Niels Keuning.

3. Creating a Custom in VS Code

A. Project setup. The Force app consists of several parts: Aura, Classes, Components and LWC and pages (Visualforce). In this blog post, I’ll be focusing on Classes and Lightning Web Components (LWC). You can compare the structure with the Model View ViewModel pattern at which the component is split in a stratification. Before creating a new LWC component, right-click on LWC and select Create Lightning Web Component, name it and the component is created. That wasn’t so hard, was it 😉. On to the next steps!

B. Building blocks of a Lightning Web Component A LWC component is a pluggable Salesforce Lightning package that exists of several parts.

▪ First part: HTML HTML is what we see in the browser. It is mainly created with the help of SLDS (Salesforce Lightning Designing System) and is placed between template tags in an HTML-file. The SLDS-elements, like input, all have a value e.g. value={fieldPostcode}. This is determined in the JS as you can see in the 4 following image.

Second part: JavaScript

• Link to HTML From within HTML which refers to a Javascript variable field Postcode. As soon as this field is updated by a Service Center agent, the value of this variable field is also instantly updated. The following example shows how a variable field can be declared on top of the class in JS and how this is initialized with an empty value. In order to also use the navigation, this class will be inherited instantly on the DatabableEx12 class.

• Link to back-end from within Javascript to create a link to the Apex back-end, the Apex needs to be registered first. This will then be a function to execute the search in SOQL. This kind of Apex registration is illustrated in the following example. In here, I’ve defined a SeachAccounts function that refers to a publicly available SearchAccounts function within the Apex CustomSearchController class.

Next, the internal Javascript functions are linked to the imported Apex back-end function, as seen below:

The searchHandler function is called from a button. Within this action, the SearchAccounts Apex function is activated. As you can see, this function is parameterized with above declared fieldPostcode variable. When calling the searchHandler function, the name of the variable is shown as stated within the Apex function. The .then part takes care of the function’s result. The result (a search results list) is shown and saved in the local variable this.data in the same way as fieldPostcode is declared. This result is then linked to datable via data={data} as seen below.

The catch part within the searchHandler, handles all errors that could appear. The following image shows the SLDS/HTML button (lightning button) that is linked to this JavaScript function searchHandler() via the attribute onclick={searchHandler}.

• Display of columns To show the correct columns in the correct order, we first need to identify them with content fields like they would also appear in the results list of the back-end search. In the next image, you can see how columns are declared as a variable and how we represent them in the data table (result list in HTML).

In the previous mentioned SLDS image (image 7) where a lightning data table is built, you can also see how these are linked to the JavaScript variable using the columns attribute onrowaction to execute an action as soon as someone clicks the search button.

• Navigating to the client’s info In order to use the navigation function, we first need to import the following standard API.

As soon as someone clicks on the button, the following onrow action event (see below) is executed to navigate to the client’s info. In this event, the ID is retrieved of the selected account within the search results and put in view mode for the agent to see all info. Afterward, the URL is built and navigated to.

▪ Back-end
• Because the back-end is written in Apex programming language, it can communicate with the database in order to execute searches. The back-end (as registered in JavaScript) needs to be defined in an Apex class with static publicly accessible functions, provided with several parameters. The following image shows this Apex function.

This function needs to be provided with the annotation @AuraEnabled to make it accessible in LWC. Next to this, it is also static because the CustomSearchController class isn’t instantiated as an object. The result is then serialized to a SearchResult list. You can see the SearchAccounts function name matches the declaration in JavaScript. Same goes for the CustomSearchController. As mentioned before, the parameters’ names need to be an exact match while executing the function in JavaScript; only then the sequence of the variables doesn’t matter. Of course, the class with sufficient permissions needs to be accessible for the Service Desk agent.

• The database interaction in the back-end can only exist because of SOQL (a kind of specially optimized form of SQL), meaning a complex time-consuming query isn’t even possible, in comparison to the standard Global Search Box where searches could take forever. In the image below, you can see how the Account object is queried, provided the Service Desk Agent has access to this object. Of course, there are other generic methods to query, in which every syntax (e.g. WHERE, AND, OR) is set up conditionally, but for now, we chose this set-up for simplicity.

4. Deploying the Custom Search to the sandbox Before you deploy anything, be absolutely sure you have the latest version! In case the source isn’t integrated into a version control system, new code can be overwritten. In VS Code, this can be fixed with a right-click on Force app, choosing SFDX: Retrieve source from Org. A similar approach is used when deploying the Force app to a test environment (provided it’s authorized on the sandbox). Just right-click on the Force app and choose SFDX: Deploy source to Org

5. Organizing the Console App o Custom template Before we could create our custom homepage, we had to make sure the Lightning Web Component has the same measurements as the entire homepage. So, we made a custom template without any columns or rows, by using de Developer Console in Salesforce. The path we followed is: Gear (Tandwiel) Setup ➔ Dev console. File ➔New ➔ Lightning Component➔Lightning Page. And we made sure the homeTemplate consists of only 1 column.

• Custom Homepage After creating this custom template with the Dev Console, we could set up a homepage in the Console App, based on our template. Within Lightning App Builder, we created a new page: Pages → New page → Home Page → Select the custom template (1 column!) instead of the standard template (several columns).

• Configuring the Lightning Web Component As soon as the Lightning Web Component is uploaded, it can be integrated into the relevant page and we can configure various settings like height and width as seen in below image.

Obviously, there are still some aspects that need to be discussed. Performance testing, the amount of data to be searched (soon there will be 8 million clients!), code optimization, paging, deduplicating rules using Duplicate Manager or Apex and so on. But I can safely say the result is good and stable. Look at our newly created Custom Search! 👇 Looking great, right?

And what about my initial draft for the customer 360 view?

Well this was it. Please also check more Salesforce blog posts at https://blog.feedspot.com/salesforce_developer_blogs/

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top