Use additional sources of data with Zendesk Connector

Hi all. I am trying to incorporate multiple data sources, one of which being the Zendesk connector, into a new index. I then want to search from that index on our Zendesk Help Center.

I have an index that has both my data from Zendesk Guide and another tool ( that is NOT the same as the one automatically generated by the Zendesk connector.

The reason as to why I am doing this is to prevent the connector from overwriting my non-Zendesk data every time that it rebuilds. I guess this is the expected behavior.

I still would like to present the results from the new index in our Zendesk Help Center. I have no idea how to use the same styling and result rendering available in the JS repo( while pointing to my new index, not the default one.

I am hoping this is a quick answer and I am missing something simple. Both my indices live in the same application.

I am appreciative for any and all help!!!

Hi @scott.havard , and welcome to the Algolia community. :slight_smile:

There’s unfortunately no easy way to achieve what you’d like.
The first thing to understand here is that in each Algolia index, you should have a common JSON structure for your objects.

The Zendesk integration was designed to index records following Zendesk’s schema pretty closely.

Here’s an example record:

  "locale": {
    "locale": "en-us",
    "name": "English",
    "rtl": false
  "id": "209176985",
  "updated_at": 17725,
  "position": 0,
  "title": "Magento - Integrate Algolia to your search page templates",
  "body_safe": " \n\tThe realtime search experience implemented by the \n\t Algolia Search extension for Magento  is done using JavaScript in your end-users browsers and therefore cannot have access to the templates of your original theme (which is rendered with PHP from your backend). Instead, it creates a search page with a default theme that you may need to adapt to fit your UI needs.  \n\tYou can customize the design of the instant search results page & the auto-complete menu editing the following files:  \n\t\n the  topsearch.phtml  file hosting all the JS logic & the HTML templates, \t\n and the  algoliasearch.css  files hosting all the CSS code. \n ",
  "outdated": false,
  "promoted": false,
  "vote_sum": 0,
  "comments_disabled": false,
  "category": {
    "id": "201022649",
    "title": "FAQ"
  "section": {
    "id": "202137945",
    "title": "Integrations",
    "full_path": "FAQ > Integrations",
    "user_segment": "everybody"
  "user_segment": "everybody",
  "label_names": [
  "created_at_iso": "2016-06-17T11:57:16Z",
  "updated_at_iso": "2018-07-13T16:47:44Z",
  "edited_at": 17725,
  "edited_at_iso": "2018-07-13T16:47:44Z",
  "objectID": "213598445"

A lot of fields in there are only consistent with Zendesk (category, section, promoted, position, etc.).

Having a common data structure is necessary for multiple things:

  1. A consistent ranking
  2. Consistent display
  3. Consistent filtering

For instance, our integration knows that Zendesk Help Center can be localized and have multiple translations for the same article. As a result, we index the locale of the article, and when searching we always filter on the current locale of your Help Center, even if it uses only one.

You should never modify the index generated by the integration because, as you said, we’ll simply overwrite it every time the connector runs.
If I understood correctly, you’re putting the whole data inside another index, and this is exactly what you should do.

But making it so that this new index fits our integration front-end would be a pain, as you would need to match the logic our front-end uses.

  • To take back the locale example, all your records would need to include a locale field too, formatted the same way than for Zendesk records otherwise they wouldn’t fit the filter.
  • Same for category, section which are necessary to build the hierarchical display of our search results.
  • Finally, as you can see in the example above, there is no link to the article in the records. It’s because we rebuild the link based on the locale and the article id because we assume all records to be on the help center. You will have to modify the JS code at least a little bit, if only to have a switch on the link to link to your entries vs your Zendesk articles.

Those are just the issues that I can find on the top of my head when thinking about it, but this is probably not an exhaustive list.

I would probably recommend you to build your own front-end implementation. It would need to be way less generic than ours which tries to fit on any website and give you much more granular control on how things are displayed.
You already found our JS repo, and you could use this as inspiration. :slight_smile: