One of our resource directories in Hawaii may have just discovered a use case for attaching service_area to service_at_location:
A program is offered at two locations on two neighboring islands. Technically, the service_area encompasses both islands. However, there is no ferry service between islands in Hawaii, so residents on one island cannot realistically reach the other one without taking a plane or hiring a boat. Our customer asked us about scoping service areas to the more granular service_at_location level so that residents of one island will not see a pin on the other island. It’s a small, but relevant, user experience improvement.
From a user experience standpoint, we can approximate this outcome by using distance radius filtering, but that will return inexact results.
Is this a use case for allowing service_area to be connected to service_at_location as well as service?
That’s a field I would expect to already be associated with service_at_location, especially for statewide agencies with locality-specific services…
service_area is linked to service which is linked to service_at_location. Services can have an array of service_area objects attached at service.service_areas.
I might be missing something, but could the service just contain two different service_areas for the different islands, and then the service_at_location object just provide the link to the service?
Hi @mrshll, we do indeed need a link to service_at_location as you say, but at the moment there is no such link.
The context here is that in the four table model, there are essentially three levels of increasingly granular data management:
organization
service/location
service_at_location
For example, a 211 will frequently have phone numbers defined for services at the service level. However, even where a service has a phone number, situationally they may need end users to call a different number for that service a specific location. So they will then attach that phone number to the service_at_location level instead of (or in addition to) the service level. My team is expected to then use the service_at_location number first, and fall back to the service number.
We have just uncovered a similar use case for service_area. This falls into the category of “the service is definitely the same, but information about interacting with the service changes based on location”.