Gravatar for

Question by ken thomas, Jan 31, 2018 7:48 PM

How to remove a field from search consideration for one pipeline

We are a Salesforce shop. In our environment, we publish knowledge so that it can be viewed by anonymous users who are not logged in.

We have a pipeline for this search called PublicSearch. We have an internal search for employees which we call AgentSearch. Both of these pipelines include Salesforce Knowledge as one of the sources.

Internal Notes on Salesforce knowledge should not be part of search consideration on PublicSearch, as these internal notes are not ever shown to the user when they view articles and contains content that the end user should never be able to see or search for.

Internal users, can view this info while logged in to SF and they should be able to search this field in our Coveo AgentSearch pipeline because they are employees and should be able to find items with the AgentSearch pipeline by searching for things that may appear in the internal notes.

I have been asking around on how to implement this and have not gotten a good answer yet. Seems that there should be a way to specify what fields are part of search consideration, at the pipeline level. I have not found any way to do this.

The only workaround I can think of is to have a duplicate source, because the only way I have found to do this is at the source, not at the pipeline.

Does any one have a similar situation, and do you have any other way to accomplish this? I am not a full admin in our environment so there is much I cannot see or try

4 Replies
Gravatar for

Answer by amoreau, Jan 31, 2018 8:11 PM

Hey Ken,

I believe the documentation you are looking for is this one:

As your condition, you can simply enter something like `NOT @fieldtoignore`. This makes it so that any item with this field will be ignored by your pipeline. I believe this is what you are trying to achieve. If you need more information on how to enter the right condition, I welcome you to check the Coveo Cloud Query Syntax Reference:

Let me know if this helped!


Gravatar for

Comment by amoreau, Jan 31, 2018 8:21 PM

I think I might have misunderstood your question.

If you mean that your Internal Notes are a field of your Knowledge articles, and wish to make them Free-Text Searchable in one pipeline, but not in the other, then I'm afraid the solution I offered you earlier might not be of help.

If, however, your internal notes are a different item, then the previous solution works.

Gravatar for

Comment by ken thomas, Jan 31, 2018 9:27 PM

The Source for knowledge includes the Internal Notes field. Ideally, The AgentSearch pipeline should search this field when an employee searches for X in a plain text search - nothing fancy - if X is in the internal notes of an article, it should be a result. If an anonymous user searches on the PublicSearch, then the internal notes should not be part of the search consideration at all. I am asking if there is a way (besides having a duplicate second source created) to have the field included in search for one pipeline and not included for the other pipeline. --- without the user having to do any special field queries or anything. Let me know if this is clear. I think this is a common scenario, for anyone that uses SF and has a publicly available kb and an internal search tool for employees

Gravatar for

Answer by gminero, Jan 31, 2018 9:31 PM

We dont support Field Level security, as you mention, you will have to setup 2 separate sources to achieve what you want. Further details on supported security features can be found at

Gravatar for

Comment by ken thomas, Feb 1, 2018 2:15 PM

I am not asking for field level security - I am asking for a way to be able to specify which fields for a source are used in search consideration per each pipeline. I think the scenario I described is a common industry scenario, and having to have two sources that crawl knowledge, just so that one field is not part of search consideration seems pretty wasteful. If it cannot be done in the pipeline, can it be done via code on the search page? it seems a bit overkill to have duplicate sources for this scenario. So, if I understand this correctly, when a source is set up in Coveo, any pipeline which uses that source, ever single field in that source will be part of search consideration for that pipeline?

Gravatar for

Comment by amoreau, Feb 1, 2018 2:27 PM

Being able to search through the content of a field is achieved by making the field free-text searchable. Of course, not all fields are free-text searchable by default (in fact, very little are).

There is no way to specify which fields are free-text searchable through the pipeline.

What Guillaume was saying that you can have two sources - one that indexes the internal notes field and one that does not. You could then specify in the pipeline which sources to query. You could also do it directly in the search interface.

This is the best solution for your use case.

Gravatar for

Answer by ken thomas, Feb 1, 2018 2:22 PM

For the suggestion of using a condition of
NOT @fieldtoignore
is there a way to enter that so that applies to any and all searches using one pipeline?

Gravatar for

Comment by amoreau, Feb 1, 2018 2:30 PM

That suggestion was made assuming the Internal Notes was its own Salesforce object, not a field on your Knowledge articles.

But there is a way to add a query expression to your pipeline, as noted in the documentation I linked earlier:

You would add it as a Condition in the Advanced query.

Gravatar for

Answer by François Lachance-Guillemette, Feb 5, 2018 4:50 PM

I might have found a way for you to do this.

If you check the Query Pipeline Language (QPL) page, you can add conditions and ranking expressions based on identities.

For instance, you could add a condition:

Then, you add a new ranking expression to _lower_ the ranking of results that matches the query, and set this specific condition. like the following:

So you cannot directly affect the "ranking modifier" of a field, you cannot directly ignore a field for a specific type of identity, but this should at least weight down the documents that pop up _because_ of this field when the user is anonymous.

Ask a question