Skip to main content

Mapping Your Resource Data to Connect 211

This document outlines Connect 211’s process for formatting resource data to be used in public Resource Directories.

Kylie Johnson avatar
Written by Kylie Johnson
Updated over 3 months ago

Prioritizing Contact Information

Data providers will store and prioritize important information in different tables. For example, some will prioritize location/site while others prefer program/service tables.

Connect 211 normalizes those differences by going to a more granular level, the service_at_location (sometimes called “program at site”) level, and then custom ranking contact data for each tenant.

When ranking contact info, we need to know two things:

  1. Which tables to reference

  2. If, and in what order, to use fallback logic between tables

Both of these things can be described by listing tables in the order they should be checked, and omitting tables that should be ignored.

For example, if we should look for phone numbers at the service table while falling back to the location table, we could define that as: service, location. If we should only check the service table and ignore location altogether, it would simply be: service.

Example Contact Info Questionnaire

  1. PHONE Where (and in what order) should we look for phone numbers? location, service

  2. HOURS Where (and in what order) should we look for hours? service

  3. URL Where (and in what order) should we look for the main URL? service, organization

Descriptive Info

Search record names usually make the most sense if we combine names from a couple tables to provide context to viewers.

Since we are using service_at_location records, the name of each record usually makes the most sense as a combination of either service at location or service by organization.

Occasionally the description field needs to combine fields too, perhaps a location description appended with a service description.

Example Descriptive Info Questionnaire

  1. NAME How should we format search record names? service | location

  2. DESCRIPTION Which tables and fields should your description be pulled from? service

Mapping One-off fields

Fields that describe service information such as fees, application process, and eligibility descriptions are usually easy to identify and map. However, if this data may be pulled or concatenated from multiple fields, or the naming is unintuitive, then please identify which source table/fields these come from.

Handling Edge Cases

The above guidelines are sufficient for a majority of data sets Connect 211 has encountered. However, there are sometimes edge cases. For example, some data sets require handling the NAME component differently depending on conditions. We really try to avoid getting that granular; more often than not our clients decide to do some data cleaning internally once they’ve seen how it displays publicly. However, there is always room for Connect 211 to learn and grow. If you encounter edge cases where the above rubrics don’t work, please describe share it with us.

Did this answer your question?