Hi @scott.havard , and welcome to the Algolia community.
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:
"title": "Magento - Integrate Algolia to your search page templates",
"full_path": "FAQ > Integrations",
A lot of fields in there are only consistent with Zendesk (
Having a common data structure is necessary for multiple things:
- A consistent ranking
- Consistent display
- 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 README.io 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
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 readme.io 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.