Closing as the new feature has been created for addressing the issue. https://folio-org.atlassian.net/browse/UXPROD-5172

@Harry Rumble,
Potential options:

1. Do not use the Retrieval SP filter in the central tenant, as it is currently non-functional there. This approach is not compatible with LoC workflow since retrieval occurs in the central tenant.

2. Investigate possible solutions and assess the implementation effort required to ensure retrieval staff can see and use the correct service points for processing requests in the central tenant. A spike for this will be taken in S210.

Thank you @Gurleen Kaur1 , @Irina Pokhylets not sure how we want to proceed, let me know any potential next steps

Hi @Irina Pokhylets , @Harry Rumble ,
I concur with Brooks' remarks that the current setup is not feasible because the location data for items in central requests does not match their true whereabouts, and the connected service point records in the central tenant are not related to the actual locations as they do not exist there. All of LC's locations are strictly confined to the data tenants. To make this work, we would need to implement location data synchronization from each member tenant to the central tenant solely for filtering purposes.
CC: @Kapil Verma1 , @Kalibek Turgumbayev

Also @Irina Pokhylets adding this info from @Brooks Travis

All of LC’s locations exist only in the data tenants. My read of CIRC-2239 is that they expect to see the retrieval service point for all requests in the central tenant, so that their retrieval staff only work there. That’s not going to be possible since the actual location information of the item on the central requests is not the actual location of the item, nor is the service point record in the central tenant associated with the location (as it doesn’t exist in the central tenant)