Hello,
Different suggestions based on the number of states served.
If a company can only service one state but multiple counties:
Properties:
Service State: Dropdown or multicheck of state codes or names, whichever standardization you prefer.
Service Counties: Multicheck of all counties with formatted names and duplicate county names removed so there is one option for that name. Recommended to have “County” as well as alternative naming patterns like “Parish” or “City of” removed. For example, if there was an “Abbeville County” in South Carolina and “Abbeville Parish” in Louisiana, “Abbeville” should only appear once one the list.
To filter for companies in a county, filter Service States + Service Counties to find the applicable combo. State should be included because a county name could exist in multiple states.
Examples: to search for Adair Cty, Iowa, the filter is IA + Adair, to search for Adair County, Kentucky, the filter is KY + Adair, etc.
If a company may service multiple states:
Option A
Decent option for maintenance and set up since it is one property You can still pull lists based on state instead of counties uses contains any of “, [STATE]”.
Property: Service Counties, All: Multicheck of all counties in each state + state code. (An example of an how these options are written is “Abbeville, SC”.)
The number of counties and state combos does come under HubSpot’s Multiselect 5000 limit. If the user starts to type the name of the county within HubSpot, the text will start to pull only applicable answers. So if you type “Adair”, all options will show up for “Adair, IA”, “Adair, KY”, etc.
Option B:
The IFTT option as you described.
A straightforward option for keeping state and county separate if that will meet user needs and expectations. Can be a pro for reporting that each state has a separate county column. Can be a con for reporting that each state has a separate county column.
Properties:
Service States: Multicheck of state codes or names, whichever standardization you prefer.
Service Counties [STATE] (x50): Multicheck dropdown of counties in one state, appearing if the corresponding service state was selected.
Option C.
Combo. The IFTT option + you described, plus additional flows to pull counties into one for reporting.
This is included because users can still intuitively filter by just state from the object’s index page, but option A could still use “contains any of” state list memberships in the index filter instead. It may be worth your time to set up those lists and train on how to filter for state if needed instead of building these workflows, but not sure what your coworker expectations are so… here.
Properties:
Service States: Multicheck of state codes or names, whichever standardization you prefer.
Service Counties [STATE] (x50): Multicheck of counties in one state, appearing if the corresponding service state was selected. The format of the counties should be “County, [state code or name]”.
Service Counties, All: Multicheck of all counties that were in the Service Counties [State], in the same option format.
Workflow (x50)
Trigger: Service Counties [STATE] is known
If/Then is Service Counties [STATE] is any of Option A:
Option A is true
Append Service Counties, All with Option A
Go to next if/then
Option A is false
Go to next if/then, Service Counties [STATE] is any of Option B.
etc.
If you need to add a clear option to remove counties when a county is removed, one flow following below could work.
Trigger: Any of the 50+ Service Counties [STATE] is known
Delay > whatever you believe is enough for someone to in theory be able to update all 50+ properties.
Then the If/Then waterfall for all options in each property.