1

How do we get Global Search to NOT show results that are NO LONGER VISIBLE to the logged in user? More quickly? Ever?

I'm noticing as we test our implementation in Sandbox that when I

  • login as TestUser A (who is in Role A)
  • create an Account TestAccount A
  • logoff
  • login as TestUser B (who is in Role B)
  • search for TestAccount A - found it (because a Sharing setup was incorrect)
  • logoff
  • fix the Sharing setup
  • login as TestUser B again
  • type "TestAccount A" in the Global Search bar - it is listed, and clickable, but when clicked, it has a "null reference" error (appropriate, as if the record does not exist - in truth, now properly hidden behind it's Role with no Sharing active now on the record)

This is not going to be a frequent issue, BUT it IS an issue for Executive and Corporate users who are testing (and could be one in Production) because when THEY click a link that is in their cached Global Search results, and get an error, they assume that something is broken. We're having a bad enough time with adoption here due to several issues (speed of our Sandbox, noncaching of Apex code, Rootstock and more).

If it happens to be SHARING related (somehow the Sharing needs to "catchup" perhaps), it's taking hours to days to do so (catchup). An Executive here was accessing a record a few days ago and she had not been in Salesforce for at least a week.


Screenshots:


User TEST SID is logged in; sees a previously visible Account TEST IDW 0303 1 in search results (no longer accessible as Sharing was removed)

Cached search results that is no longer a visible record


Clicking on the cached Search result, they get an error, the first sentence of which is what's relevant

Error when clicking now-invisible cached search result

  • You don't mention it but you use the recalculate button on the sharing rules? – Girbot Mar 3 '17 at 15:10
  • No. It was technically GROUP MEMBERSHIP that was the issue that spawned this in reality. User Alpha was a member of 5 groups (that had Sharing access to five divisions of records). They were then TAKEN OUT of all but ONE GROUP, and they still saw the cached search results. Sharing RULES themselves was never affected. – AMM Mar 3 '17 at 16:31
  • If that was the solution then write it up as an answer :) – Girbot Mar 3 '17 at 18:17
  • No solution yet. – AMM Mar 3 '17 at 18:22
1

The answer here based on my investigation is that the MANAGED PACKAGE (in this case, Rootstock) that is trying to render a record to the user needs to handle the record ID no longer being visible (or even perhaps deleted). They are assuming the ID being passed is both present and visible to the User requesting it.

Or maybe more simply: They need (better?) Try-Catch logic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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