Back in the days, if you were using Coveo for Sitecore version 4.1 or older, every single template field that was being indexed by Coveo was suffixed with this hash number, which had different values between your different sources (master, web, pub, you name it).
As you guys can imagine, there was a reason for that. You can read the official documentation about it right here, but basically, the goal was to make sure that Coveo was able to keep different field names on its index (one for each Coveo Sitecore Source) for the same field name in Sitecore.
That’s why your absolutepath in Sitecore would become fabsolutepath1234 on the master source and fabsolutepath5678 on the web source, with the hash part varying based on the source’s name. By doing that, if an author changed a given configuration on this field on master, that would not break the web search page, which would be using a completely different field name on production.
“So… Why Was This Removed?”
In a few words, this scenario makes a lot of sense in theory but occurs very rarely in reality since administrators almost never change a Sitecore field type.
And not only that, it obviously increases the number of fields on your instance by multiplying the number of fields by the number of sources you have, which can easily become a problem since this number has a limit defined in your license (usually 5000 fields).
That’s why the paradigm has changed.
Now Coveo only creates one indexed field for each Sitecore field, and if you ever need different configurations between different sources for the same field, then you can set the field flag isSourceSpecific=true as described by the Coveo official documentation here and here.
Protip: In the worst case, if you forget to change this flag to true and decide to change a field configuration that can break one of your environments, Coveo will keep the less destructive value on its index.
For instance, let’s say that you have a field that was IsFacet=true and you try to change it to IsFacet=false, that would break any search page using this field in a facet component, right? That’s why Coveo will keep IsFacet=true on the index and add a warning message in your logs.
“That’s Awesome! What Should I Do To Take Advantage Of This?”
If you are using the new Coveo for Sitecore 5, then you don’t have to do anything. By default, the fields won’t have the hashing and you are good to go. The IsSourceSpecific flag is also there, so make use of it if you need it.
By the way, any new project should be using this new version, otherwise, the Sitecore Gods will have no mercy on you. I have a blog posts series talking about the amazing Coveo Command Center, which is present in this new version, you should take a few minutes and read it.
However, if you are still using the Coveo for Sitecore 4.1 the answer to this question is it depends on how recent is your version.
If you have installed Coveo for Sitecore 4.1.590.2 – September 2018 or a more recent version, then you are lucky. Basically, there is this new configuration called PreferSourceSpecificFields which has false as the default value. By keeping it as false, you are telling to Coveo to only add the hashing on those fields which have the previously mentioned IsSourceSpecific=true flag. Again, that will reduce drastically the number of fields you have in your Coveo organization.
However, if you are using Coveo for Sitecore 4.1.518.18 – August 2018 or an older version, I’d recommend you to upgrade to a more recent version, otherwise, there is no way you can benefit from this new feature. I’m sorry. Really. No other option.
There is no better way to reduce the number of fields than by removing the hashing on them. It’s almost magical.
This is just one of the reason why you should upgrade to Coveo for Sitecore 5. Besides the Command Center, there is way more on this new version. I’ll keep blogging about all those new features, so make sure you follow me on twitter @hsantos_x and don’t lose anything useful for you or your project!