How to add another Index to Zendesk Search for Employees only

I have an index which includes all our public searchable content. Search is great and people like it.

We have additionally a lot of good information which is employee restricted only and have not added that to our index as it is restricted and don’t want to make that available publicly.

I was thinking about adding another Index with the employee related content and then add the index somehow to the search when person searching is an “agent” within Zendesk.

Is this the right approach and can you provide some samples / hints how to accomplish that easiest?

BTW: I am using my own index populated by our own scripts and not the default which comes with the AlgoliaSearchZendeskHC

Appreciate any feedback.

Hi Daniel,

Thanks for contacting Algolia Support.

As documented at the support documentation link below, we do not index private articles for security reasons:
Our Zendesk integration can only provide front-end code. This code is inspectable by anyone visiting your website. So while we could restrict the search depending on the current user permissions, nothing would prevent a malicious user from modifying the request sent to Algolia and being able to list private articles.

As a result, we chose the safe and secure route to only index in Algolia public articles.

Our suggestion in this case is to use our autocomplete menu.

The standard setup does two things out of the box:
Replace your search page (/hc/xx-xx/search) by an Algolia-powered search, with filters on the side and pagination. We call this “instantsearch”.
Add a dropdown menu on all the search inputs on other pages. We call this “autocomplete”.
The next step is to disable instantsearch, thus restoring the default Zendesk search (with private article support) on the search page.

The end result is that:
an end-user will be able to use Algolia to quickly find their answer
a Help Center agent will be suggested public articles while typing, but can still press Enter to find private articles
If this sounds appealing to you, changing our integration to behave this way is easy. You need to replace in your Help Center document_head template this code:

applicationId: ‘’,
apiKey: ‘’,
subdomain: ‘’

By this code (There’s an extra comma at the end of the “subdomain” line, don’t miss it or you’ll get a syntax error):

applicationId: ‘’,
apiKey: ‘’,
subdomain: ‘’,
instantsearch: { enabled: false }

Please let us know if you have further questions.
Best regards,

Hi Daniel,

Could you expand on what you mean by:

I am using my own index populated by our own scripts and not the default which comes with the AlgoliaSearchZendeskHC

Are you using the open-source script of the connector or a fully custom-made script?

Also, are you using AlgoliasearchZendeskHC for the front-end or also a custom script?

Hi Jerska,
I wrote my own scripts to populate the index although made sure to structure the json accordingly to the AlgoliasearchZendeskHC front-end needs.
I do use the AlgoliasearchZendeskHC front-end but have forked and customized it as I am using different naming convention for the index and some other smaller tweaks as I have included other content from other sources as well beyond what is available in zendesk.

You actually helped me with that a while back. And thanks again for that it works great.

Now that I got everyone to use the search and they love it I got the request to include also the “internal” KB as part of the search but only for employees which at least theoretically I thought would be easy.

When they are logged in I know they are Agents and I can pull the information from zendesk.
So I thought adding an another index with the internal Doc and only query and show those results (before or after) the official results if they are Agents within Zendesk.

Thanks for clarifying, this makes perfect sense.

I believe you’ll face the same issue as we did if you try to do this.
You need to differentiate between agents and normal users. This value is accessible in two different places:

  • JavaScript: window.HelpCenter.user.role
  • Templates: {{ user.agent }}

The template variable unfortunately only works on the user profile page, so using it is out of question.

Unfortunately, using the JavaScript variable is also not an option if you have sensitive information in your private articles. Indeed, JavaScript code can always be inspected by users, who could easily change the logic to target the private index.

Indexing private articles too is really simple.
We’ve implemented the logic here: .
This logic allows you to accept every article if CONFIG['private'] == true, or to whitelist only some user segments (CONFIG['user_types'], defaults to ['everybody']).
The only issue is securing the front-end.

The only solution we’ve found to this issue was to create a dedicated page / website only accessible to your agents which would target this “private” index.
If you choose to do this, you should also create a custom API key for your public index, restricted to search in this index, so that users getting your API key from your public search could not search in your private index.

thanks for the details. Appreciate the information.

I am considering the creation of a separate page but I am worried about the adoption.

Ignoring having sensitive information in our private articles and people picking the internal index name… etc. , where would you add the additional search in AlgoliaSearchZendeskHC?
I have an index with only the internal articles and I want to show them after the “public” search?

I would suggest that you’d simply index everything in the “private” index, and chose which index to target at load time:

  • Public: only public articles
  • Private: public + private articles

Otherwise, to add them after, you’ll need:

  1. For the autocomplete, to add an extra source to the autocomplete menu.
    You should be able to reuse most of the templates
    The documentation is here: .
  2. For the instantsearch page, you can only target one index at once.
    A possibility would be to instantiate two different instantsearch.js instances.
    The documentation is here:

Thank you for your help