Skip to Content
Author's profile photo Stephen Millard

OrgChart 4.1 Quick Search Essentials


In February (2014), Nakisa released version 4.1 of their suite of visualization solutions.  This saw a number of updates across both the org visualization (SOVN) and talent visualization (STVN) applications.  Amongst these was a new SOVN OrgChart feature called “Quick Search”.

In this post I’m going to take a look at this new functionality and provide…

  1. An overview of what Quick Search is for and how to use it.
  2. A quick peek at some of the Quick Search configuration.
  3. A look at some of the key behaviours of Quick Search.

In a subsequent post I’ll be taking a look at some additional search query syntax that’s guaranteed to boost your credibility as a Quick Search power user.


In previous versions of OrgChart, searching was always carried out via the listings functionality.  By default this provided three search options – employee, position and organizational unit.  The new Quick Search feature allows users to search for employees (only) from an input field that is located at the top of the OrgChart interface – i.e. you can search from the chart without having to switch over into a listing.

01. Quick Search.png

As you might expect, the new feature is also available in the OrgHub for Mobile application.

02. OrgHub for Mobile Quick Search.png

To use the Quick Search, a user need only type their search term(s) into the Quick Search field.  As they type, the system will automatically begin retrieval and as more characters are entered, the list will be filtered to reflect the changing search parameters.

03. Basic Search - Anja.png

The results are displayed immediately below the field in a dynamic list.  By default the search term(s) are highlighted in the results showing exactly what has been matched on.

The set of data fields searched  is the same set of fields that will be displayed, or rather where there is data being held.  For example, note in the result set above that only Anja Müller has a telephone number.

The six available fields are:

  1. Employee Name.
  2. Location.
  3. E-mail.
  4. Telephone.
  5. Cell Phone.
  6. Fax.

Selecting (by clicking; or tapping in OrgHub for Mobile) one of the results opens the corresponding employee details  panel.

04. Employee Details Panel.png

By default, OrgChart will return the first five results.  An option to load more is then displayed.

05. More Results.png

Selecting “See More” loads the next set of five results and scrolls the list down.  This process may be continued until there are no more results to load.

06. Even More Results.png

In OrgHub for Mobile, the results and process are similar though there are a few notable differences.

07. OrgHub for Mobile Results.png

08. OrgHub for Mobile More Results.png

The first is that a few “null” values start creeping into the results.  Whilst this doesn’t invalidate the data it does detract a little from the cleanliness of the results and means that more scrolling to view results may be required.

The second is that rather than up to five results being returned by default it returns up to fifteen (this is actually a configuration option in the build).

When the bottom of the initial results is reached, an option appears to allow the user to load additional results.  Rather than loading an additional five results, the default (again build configurable) is to load a further ten results.


The Quick Search feature is currently only available  for live (or hybrid) builds.  The basic configuration can be achieved by setting the QuickSearchSAPConnection connection string (in AdminConsole) to point to your desired SAP system.  The user account it uses for the connection will of course require a suitable level of access to enable it to surface the desired search results.

57. QuickSearchSAPConnection.png

Once the connection has been configured, when the build is published it will trigger an extract to run in the background (the publish will complete meanwhile as normal).  Nakisa estimate this extract usually takes around 15 to 20 minutes to complete.  The extract builds a search index file that is stored in Root\Database\QuickSearchIndex.  The index is then kept up to date  by a periodic  “delta” update process – the admin guide states that by default this occurs every 30 minutes.

There are also a number of files (QuickSearch*.txt) within the SettingsResources directory that can configure various options for the search.

If you recall I mentioned earlier that OrgHub for Mobile returns a default of fifteen results and a further ten results per “See More” selection.  These are both options available by specifying a numeric value in the QuickSearchMobileInitialCount.txt and QuickSearchMobileIncrementCount.txt files respectively.  Unfortunately these options are not configurable (in this first release) for the browser based version.

Interestingly there is also a QuickSearchMinUpdateInterval.txt file.  This file contains a default single numeric value of 3000000.  I’m not sure if this actually relates to the index update frequency for Quick Search, but assuming it is and that it is a timer value specified in milliseconds (a fairly standard convention for many systems and programming languages based on factors such as system clock accuracy), this would equate to 50 minutes rather than 30 minutes.

Behind the scenes, the Quick Search appears to run on Apache’s Lucene  (v4.3).  This is a widely used full text index and search engine system and is released under the Apache license.  So basically it is a proven technology requiring no additional licensing costs to make use of it.

Search Behaviour

With the release of Quick Search I decided to spend some time experimenting with it to see if I could figure out if it supported any advanced search features.  The good news is that it does.

Extended Characters

First of all I thought I’d take a look at the use of extended character sets.  You may recall from an earlier example that Anja Müller was in the search index.  So I decided to see what would happen if I searched for “Muller” and “Müller”.

09. Search Muller.png

10. Search M-u-ller.png

As you can see the results are identical and inclusive of the name “Müller”.  Reducing the search term however to just the first two characters gave differing results.

11. Search Mu.png

12. Search M-u-.png

So from this we can see that searching with an accented character will return only results containing that accented character, whereas searching using an unaccented character will return unaccented and accented character results.

Wild Cards

On occasion you may wish to carry out a search where you perhaps wish to put in some place holders that could represent other characters.  These place holders are typically referred to as wild cards and there are a couple that seem to work for Quick Search.

The first wild card is a question mark (“?”).  This character represents exactly one character and can be placed anywhere in the search.  Placing it in the middle or the end for example give the sorts of results you might expect.

30. mu-ler.png

31. mulle-.png

Putting the question mark at the start did give good matches, but doing so also caused the null values to reappear.


Multiple question marks may also be used (consecutively or non-sequentially).


  • mu??er
  • m?lle?

The second wild card is the asterisk (“*”).  An asterisk optionally represents multiple characters.  i.e. it may represent any number of characters including just one character or even no character at all.

33. mu_er.png

Again the asterisk can be used at the start / end (though when used at the start, null values can appear) and multiple asterisks may be included in the search query.

34. m_e_.png

It is of course also possible to combine the use of both types of wild card.

35. mu--e_.png

There are also a couple of SettingsResources files that are applicable here – QuickSearchEnableLeadingWildcard.txt and QuickSearchEnableTrailingWildcard.txt.

QuickSearchEnableLeadingWildcard.txt contains a single boolean value of “true” or “false”.  By default this is set to “false”.  This setting controls whether to prefix search query terms with an asterisk wild card.

Logically enough, QuickSearchEnableTrailingWildcard.txt also contains a single boolean value of “true” or “false”, but by default this is set to “true”.  This setting controls whether to append search query terms with an asterisk wild card.

So what does this mean for building our search queries?

If we search for the first few characters of an employee’s first and last names without and with asterisks at the end (to replace the omitted characters), we can see that the results are identical.

50. an mul.png

51. an_ mul_.png

If however we take the last few characters of an employee’s first and last names without and with asterisks at the start (to replace the omitteed characters), we can see that the results are in fact quite different.

52. ja ler.png

53. _ja _ler.png

So this is an important behaviour to keep in mind and understand.  If you are searching for example for someone’s name, typing in the first few characters will yield the result, but if you miss any of the first few characters you’ll need to prefix an asterisk.

54. mulle.png

55. uller.png


With the introduction of Quick Search into OrgChart, Nakisa have brought a new style of searching into their application suite.  One that is much more akin to the types of searches must of us execute every day via our preferred internet search engine.  This gives users a much more familiar way to interact with the organisational data and has the potential to improve the amount of use OrgChart gets from users and to improve user’s productivity as a result.

So that’s my brief look at the essentials of Quick Search, but like any modern search engine, there’s more power waiting to be tapped by those who know how to use it.  In the next post I’ll be taking a look at some of the Quick Search query syntax that will be a must for Nakisa consultants, admins, trainers and power users.

Authored by Stephen Millard.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi Stephen,

      many thanks for this article.  I was wondering if in the quicksearch the SAP authorizations are taken into account?  E.g. if a user doesn't have access to a certain person in the backend, will it still appear in the quicksearch?

      Many thanks for your feedback,


      Author's profile photo Stephen Millard
      Stephen Millard
      Blog Post Author

      Hi Tom.

      If you refer back to the configuration section, you can see there is a separate data connection used to read the data in from SAP.  Therefore it will be the authorisations associated with the SAP account used for that data connection will determine what users appear in the search.

      I haven't had an opportunity yet to try this on a system with known authorisation restrictions in place, but judging by a particular comment during the VSN 4.1 delta training webinar it didn't sound like there were any additional checks that might filter restricted results out of the Quick Search list.



      Author's profile photo Former Member
      Former Member

      Hi Stephen,

      Thx for your reply.

      I thought that the user in the connection string was used by the system to create the index file (1 index file for all users so no additional checks per user). 



      Author's profile photo Stephen Millard
      Stephen Millard
      Blog Post Author


      Yes - the index file is used as the basis on which to build the set of search results.  Therefore the authorisations in place for the account used to build the index would in effect apply to the Quick Search for all users.

      In theory Nakisa could then use the usual (Live) SAP connection to carry out an additional check to read in data about each of the results returned in a particular fetch (since not all results are displayed in the first tranche) and any that fail to return the requisite data (i.e. due to user auths) could then be filtered out ... but I don't believe that this is currently being done.  Maybe it will be in the future?



      Author's profile photo Former Member
      Former Member

      Hi Stephen,

      I have installed Orgchart 4.1 and provided connection string for quicksearch.

      It's more than 2 hours now, i dont see anything in the index folder:


      Can you please suggest any workaround?



      Author's profile photo Former Member
      Former Member

      Hi Hardeep,

      Next time please submit an entry in the Nakisa forum if you have an issue with your implementation of Nakisa.

      To solve the problem you are reporting, I had to delete the /database/QuickSearch folder and restart the application server for the indexing job to stop failing.