Getting changes to Lookups to trigger a crawl


We're using a Lookup column to link to master data.  When the master data is updated, the changes are applied to the content via the Lookup.  While this works well for the browsing and filtering within the list view, the update to Lookup pull-through data does not appear to trigger a crawl.  We use these properties for search purposes (refiners) and need them to be updated.  Is there a way to trigger the crawl when an item is updated in the Lookup list for the libraries that use it?

5 Replies

@melkinsco I'm going to guess here, but I think it might be because updating the Master Data doesn't actually update the records that lookup to it (because that is related by ID). To confirm, make a change to your master data and check the modified date of your related records... I do not think the modified date will change.

I'm guessing... that because of this, SharePoint doesn't recognize it was a change and doesn't re-crawl your item during an incremental crawl. It would only be picked up during a full crawl which we have no control over in  SharePoint online.

To test, you could re-index the list and see if SharePoint picks it up during the next crawl. How often  is your Master Data changing? If it's not often, scheduling a re-index is likely fine... however,  if it's changing often, the re-index will put a heavy load on the system and should be avoided, and you may need to look into another approach for refining on master data.

@Beau Cameron 

Hi Beau! You are correct all around.  The change in the Lookup list is bound to the lookup key.  The key is what is used at the library level and the rest of the data is associated to the key.  If a change is made to the lookup list itself (not the key, but any value associated to it) it does get pulled through into the consuming library.  Also, as you noted, if we re-index the library, which we are forced to do now, the new value will be picked up for the search.  It's just not a very elegant, nor practical solution in the long run.


The reason for the Lookup is that, by having the data local, we do get crawled properties that we can use for search refinement.  Very hand in certain business cases and the access to the external data brings in guaranteed data quality.  Secondarily, when data changes, it typically changes outside of the content platform.  Example:  When an employee retires, their retirement data is set in the HRIS system.  That event should trigger a number of things in SharePoint automatically, especially from a compliance perspective.  Also, name changes, etc. to ensure that the information can be found both by the historical data as well as the current data.  The goal is to eliminate stale content.  While the document itself may not change, the information about what the content relates to quite often does.


Lastly, we sync the master data with the SharePoint list on a periodic (nightly, weekly, etc.) basis.  This ensures that we're always in sync with the source data, now and into the future.  The sync process allows us to have local data which gives us the crawled properties and ability to provide strong sorting and filtering for the industries we serve.

@melkinsco Hi Michael! :) How is data normally presented to users? Do users open up the items and click  on the lookup columns to find more information on the master data... or are you possibly using term driven pages to present some of this content to your users?

@Beau CameronThe users don't see the source list, only the library where the Lookup is applied, and any of the pull through values are available via the view in the library.  If a value changes in the list, it is automatically reflected in the library right away, and available for filtering, etc..  The other way we make the info is available is via search interfaces as any of the pulled values can also be used as refiners.  Of course, without the crawl, the search interface is behind a bit...

I think it is an obvious oversight in the architecture of Lookup columns. Microsoft should fix it that when a lookup column is configured on a target list the re-indexation is expanded to both source and target lists automatically when an item on the source list is changed. How to get this kind of 'niche' flaw noticed by the powers that be, is another question though