We're all excited about the Enterprise-wide Search announced at JiveWorld17.
But what if you cannot wait?
Since I embarked on my career of architecting knowledge bases and search solutions, I've always seen them as going together. There seemed no point of having a central collaboration hub if it wasn't backed by a search engine which brought content in from various sources and allowed them to be searched from a single place. I've seen some organizations replace Jive Search completely, while others have attempted to plug in Search Engines as Bridged-Communities using the OpenSearch technology/format, which serves up search results back in Jive.
I've tried to tackle this problem with two approaches.
My first approach has been content syndication, where I imported and archived tickets and defects into my knowledge platform/collaborative intranet, where the contents of the source could be viewed/commented on from our collaborative intranet. Basically creating copies of all the source content in Jive - bypassing the need for a separate search engine.
My second approach was the aforementioned - a separate enterprise search engine which is OpenSearch compatible, and can be plugged into Jive through Bridged Communities. Then one enterprise system at a time, one can develop adapters and search schemas for each system, mapping common search fields for better searching and filtering across systems.
Second, the OpenSearch protocol does not support Double-quotes for verbatim searches, which I believe many people are accustomed to.
Third, the results are not always pretty - when not properly implemented.
The internal Helpdesk team at Medidata asked us if we could make their content searchable from our Jive-intranet, but have it be consumed in Zendesk Help Center, because apparently this helps the agents see what a user read before creating the ticket.
After a little thought, we came up with a plan. It's similar to the previously mentioned content syndication integration, except it strips all the content formatting, and then sets the target Jive document format to be invisible to the user. It does this by setting the font color to white and font size set to 2 pixels.
We then add a big button that says "Are you looking for TITLE OF SOURCE DOCUMENT?", or in the case below "Click here to Access Document" which is a hyperlink to the source document in Help Center.
We call this the white-on-white approach. The document in the screenshot has hundreds of words below the blue button but they are so small and the color is the same as the background so they are not visible to the user. It is worth noting that as Jive RTE auto-links emails, you will see small blue dots on documents with email addresses. But a work-around is to just replace @ with _at_.
Basically this solution makes Jive a search engine of Zendesk. It is a hack, but it works now allowing for Zendesk content to be searched from Jive Spotlight search
and then directing people to Zendesk HelpCenter.
Just a word to the wise, don't ever do this on an external Jive Community, it's considered SEO spam and will get you blacklisted by Google. But it works great inside an Intranet.
To make this work in your community you can simply download the code, and set it up on your middleware server and set to a cron and your good to go. It keeps the "search pages" in sync with the source Zendesk Help center by deleting/update/creating the corresponding Jive document for the Help Center articles.
Of course we are still waiting with bated breath for Enterprise-wide search, but until we get that, why not implement this solution. If you need help, feel free to comment below or reach out to me directly.