As you may or may not know, there is a mandatory field called "Reason for Service" that appears on many service types, such as Admissions, and Diversion, and Goods & Services, and Group Activities, and so on.

What you may not know is that the "Reason for Service" field on the Goods & Services module uses an entirely different lookup table, called "Reason for Goods & Services" with an identical initial list of values. However, it's a separate table and it's also stored in the database differently. Up until fairly recently, this meant that Goods & Services were excluded from the vw_ClientsServices view, and then a workaround had to be developed.

I am not privy to the information about why it's a separate table, but I can assume that someone pointed out once upon a time that the reasons why people are provided with Goods & Services are different than the reasons why people access shelter. This is true, but it's also true that the reasons why people access Group Activities are different, and so on and so forth.

I am wondering if a more efficient solution is this: use a single table, Reason for Service, but then have configuration for each value to indicate which modules they appear in. This would be a similar approach to the Session Activities being connected to specific Desired Outcomes, or Housing Types being available for use in the Housing Placements module.

Although this may appear to be a thankless task, it could open up some opportunities. For example, right now the Reason for Service field on Group Activities is mandatory but basically useless since the reason applies to all participants, but if you change the drop-down to only have two or three options that are relevant, those changes are also applied to Admissions and Turnaways and Diversions. Similarly, the Reason for Service for a Housing Loss Prevention or Housing Subsidy is going to be quite different for a reason for a shelter Admission. The Reason for Service field is notably missing from Case Management, Housing Placements, and assessments. Not necessarily saying it should be added to those places, but adding the ability to customize per module might change the conversation somewhat about whether that would be a useful addition.