For a while now I’ve been considering how our roles as developers have changed since the advent of Qlik Sense. There are many differences although for this post I’m going to focus on the search function, from an optional object for QlikView and an integrated part of Qlik Sense.
In QlikView it was fairly common to place a search object in an convenient empty part of the screen, there was a number of options (Making QlikView searches easy and clever searches using a variable) although most left the default setting as is. Honestly I don’t think it was used by the customer much, the whole guided analytical nature of QlikView meant they didn’t really need to.
Now we have Qlik Sense things have changed. As standard we have the Smart Search, Selections Tool and Insights where the user can interrogate the data and fields. I’m going to focus here on the smart search in regards to field values (not visualisations).
Lets take the next table as a fairly standard example of what we could expect from a clients database:

Customer Table
Nothing wrong here, we could load this in and it would link to our data model via CUSTOMER_ID without any issues although as users are searching the data more and more we need to make a few changes.
Firstly we remove the CUSTOMER_ID from search results. There’s a number of ways of doing this in the script the command Set HidePrefix = ‘%’; removes the field from everything listed below so we’ll use this and rename the ID field to %CUSTOMER_ID
- Search Results
- Current Selections Bar
- Selections Tool
- Field list in Edit Sheet Mode
The next thing we’ll do is remove fields we’re not interested in. CREATED_BY and LAST_MODIFIED_DATE are not required so they’re gone!
Now lets think of the remaining field names. Are they descriptive? Do they read well? Lets change them!

Customer Table Modified
I recently did a post which talked more about naming fields in Qlik Sense and what additional things needed to be considered There I’m looking at the rename process for a slightly different angle…
Okay so what next? Well lets think about how a user would search the data. In this example they’re looking for a specific customer in London although they can’t remember their actual name. Lets search London:

Search London
We’ve got two results, one of which is a street name and not helpful to our quest. The second is the city! Its a result but is it a helpful result? The user would have to take further steps the find the right customer by name and assuming that field isn’t on the sheet as a filter those steps are a bit involved. The user would have to use the Sections Tool Search to find the field and the possible values within……..
We could make it simpler for the user and combine all the key customer details into a single field. We could replace the existing fields or we could create new a one (we’ll create a new field called Customer):

Customer Load Script
Now lets search ‘London’ again:

Search London
We can now see all the address information pertaining to customers in London. Clicking anywhere in this result selects all the possible Customers and now in the current selections we can interrogate that field further:

Current Selections Search
You can now quickly see and remind yourself of the customer you were looking for (If you hover over the line you get the full field value in the tool tip.)
To summarise its so important in Qlik Sense that you take your time with the data model ensuring it works with the needs of the user. Spend time with them and see how they interact with the data. These changes are often subtle, perhaps they even go unnoticed although they can make a huge difference to the user experience!
Hi Rich,
Interesting blog post, I like the concept of concat Customer’s fields for searching purposes. Just on the Set HidePrefix = ‘%’;, there’s a function called Search Include/Exclude which I think could be useful as well. Search Include *fieldlist
Search Exclude *fieldlist
LikeLike
Thanks Gabriel.
LikeLike
Pingback: Stop storing your Qlik Sense Expressions in Variables! | qlikcentral·