Is there any detriment to increasing the frequency of Coveo updating the security cache (the on-prem edition)? I noticed it's set to do it nightly at midnight, but if new users register during the day and are assigned security groups, documents that are restricted to those security groups won't be available to those users until the security cache is refreshed it appears. (Similarly if a user's permissions are changed mid-day.)

Am I wrong in this assumption and leaving the cache alone is fine? I mainly ask because I'm working with the security now, and if I add a role to a user, the item secured by that role isn't available to my user via Coveo search until the security cache refreshes.

  • If you have set up your security using Roles and assigned those to Items, then it should be indexing roles. Searches should be using Roles too... that would be my assumption of how search in general should be working though...
    – jammykam
    Commented Feb 6, 2018 at 17:18
  • It's indexing the roles just fine, but with Coveo, it seems that security changes aren't necessarily immediately pushed up, unless the item in question is published. When I look at the "effective combined permissions" in Coveo after making a role change to a user, it's not reflected immediately. I'm not sure how that is for Lucene or Solr, so maybe that's true in general. Commented Feb 6, 2018 at 17:28

1 Answer 1


Starting with Coveo for Sitecore 4.0, some event handlers were added to specifically handle this use case.

In the Coveo.SearchProvider.config file, the EntityEventHandler class is hooked on many Sitecore events.

user:created, user:updated and user:deleted should all trigger a security cache update for this specific user, which means its roles should be expanded and new security applied.

In the October 2016 release (4.0.450, later hotfixed to 4.0.704), some events were added to handle the roles which fix your problem:

role:created, role:deleted, role:usersAdded, role:usersRemoved, role:rolesAdded, role:rolesRemoved should trigger a security cache update when a specific role changes.

So the solution would be to upgrade or code your own handler on this event to refresh the cache.

As for your comment:

... it seems that security changes aren't necessarily immediately pushed up, unless the item in question is published.

The update of the document forces an expansion of the users from that document, which picks up the new changes.


After the October release, a bug was found in which the role:usersRemoved and role:usersAdded were not properly updating the security cache. So the user was still pushed with its updated roles but was not refreshed until the next security cache update.

This bug was fixed in the January 2017 release (4.0.895), tagged with the issue number SC-1480.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.