Adding contact information for multiple persons in your store locator might be important if you are managing a locator with the following requirements:

  • Multiple physicians at each practice
  • Multiple products at each location
  • Multiple bankers at each branch
  • Multiple personal trainers at each gym

This can allow you to display location pages with multiple related records as shown on this example:

https://locationswithdoctors.locationlandingpages.com/United-States/CO/Denver/Sample-Location/68773/6485

Scroll to the end of that page to see doctors that practice at that location.

In these scenarios there might be 1, 2 or even 200 records related to each location.  MetaLocator allows this type of setup through our suite of relational features.  Relational features should not be used when the related object is not complex.  For example, if you can represent a "product" using the MetaLocator Category system, there is no reason to use these relational features.  However, if the related object needs its own detail page, custom fields or needs its own dedicated search interface, relational is the way to go.

"Relational" refers to the connections between locations and the other data types you might be managing.  For example, if you have multiple persons at a given location, locations and persons are said to have a one-to-many relationship.  If those persons are then related to multiple locations in turn, then locations and persons are said to have a many-to-many relationship.

MetaLocator handles both one-to-many and many-to-many relationships.

Database jargon aside, let's dive into the first scenario where we have multiple physicians at a given location.  This is an example of a one-to-many relationship.  If you are creating a product finder, personal trainer finder, or other data type, you can replace the word "physicians" below, with a more appropriate noun.

The first step is to create another table to store our Physicians.  Under Data > Tables, choose New.

(If your account does not have access to the Tables feature, request it from the Helpdesk)

Enter "physicians" for the table name.  Table names should be a single lower-case word, a noun, that describes the object that the table will store, preferably in plural.  This word can be used in SEO URLs later on, such as /physicians/Wisconsin/Milwaukee/John-Smith-MD/ so simple is best.  Click Save to create the new table.

Now that you have a new table, we need to add data to the new table.  We can add data manually or import in bulk as described below:

Adding Data Manually

let's add a few records manually to get started.  Under Data > All Records, choose Add.  Notice now that you are prompted to choose a table first.  Choose physicians from the table list and click Go.  Complete the form by adding a record for the first physician.  You only need to enter the name, however; in this example, we will enter a name, description, phone, photo and email.

Notice that we are not adding address or location data here.  Later, we'll attach this physician to a location.

Save the new physician record and repeat the process for a second physician.  This will allow us to demonstrate the "many" side of the relationship.

Importing Data in Bulk

There are multiple tutorials on importing data into MetaLocator.  We won't repeat those steps here, however, when importing data into a table other than the primary locations table, notice now that you are prompted to choose a table as the first step in the import process.  Choose physicians from the table list and click Go.  Follow the prompts to import data in bulk.

Geocoding is often not needed for importing persons since the address data will come from the related location, so despite warnings, you can skip that step.

If you haven't already, import your location data as well.  In this example, we presume these are hospitals, clinics or similar practice locations where these practitioners are available.  However, when you import locations, be sure to choose Locations from the table list prompt.

You can also import your location data and your contact data in the same spreadsheet.  We will cover that later in this tutorial.

Relating Records

In order to connect a location to a physician, we need to create a special type of field in the locations table.  This field will be called "Physicians at this location", and the field type will be "Related Table".  First click Fields, then choose Locations if prompted for the table.  Click New and enter "Physicians at this location" without the quotes in the Name field.  Choose Related Table Link from the Field Type drop-down, then choose physicians as the related table, as shown below:

Click Save to continue.  This field will expand to the full list of "Physicians at this location" when added to the Interface output.

Next, to connect a given physician to a location, edit the desired location record, and navigate to the Custom Fields tab.

 To attach an existing physician record to the location record, click Add Physician.  In the resulting window, select the desired record, and click Choose Selected.

Save the location record, and the physician will be attached to the location.

Relating Records in Bulk

In order to connect records together in bulk, a 3rd data import, called a linking table can be used.  This process is covered in detail the Event Finder tutorial.  The concept involves importing a special file with only two columns.  Each column represents a unique key, one for locations and another for the related record (in this case a physician ID number).  You can use a MetaLocator-assigned ID number, or you can create your own External Key.  A sample linking table for events can be found here.  To obtain the MetaLocator ID, export your table with the "Include MetaLocator ID" option checked as shown below:

Displaying Related Physicians

Now that we have our data structure in place, we will create a typical MetaLocator interface dedicated to displaying locations.  Click Interfaces > New > From Template and choose any layout you prefer.  Within this interface we will display Physicians in two places.  First, in the map marker popup, as shown here:

Also, we will display a list of doctors on the location detail page.

To create this display, add the Physicians at this Location field into the Map Popup Template and the Detail Page Item Template as shown in this tutorial.

Once the field is added, we need to dictate how the related records will display.  This is controlled by options found in the Data Type and Relational Settings of the Interface.

The first setting is the Display Format.  In this example we are using Directory List.  This format leverages a table-specific template shown under Related Table Settings as shown below:

The system will use the template found under "doctors" (or whatever table name you have chosen for physicians) when rendering a list of related records.  In this example, the full content of that template follows:

<div class="row">
<div class="medium-2 columns">{image}</div>
<div class="medium-2 columns">
<h1>{title}</h1>
{phone}<br />
{email rel='modal' innertext='Email this doctor'} | {email rel='modal' innertext='Schedule a Visit'}
{link} <br />
{taglistwithdescription mltable="doctors"}
{clr}{details}
</div>
<div class="medium-8 columns">
{description}
</div>
</div>

This template yields the following layout on the location detail page:

Notice that these related records are linking to the Details of the individual physician.  This is certainly optional, but showcases MetaLocator's ability to link between interfaces.  Clicking on the detail page for a physician yields this layout:

This detail page is actually controlled by an entirely different interface.  The current interface identifies this second interface as the doctor interface by looking it at the other interface's Data Type and Relational Settings.  It sees that this interface is the handler for doctors based on this setting:

This allows you to create a bi-directional relationship between doctors and locations.  In this example we've explored the location -> doctor relationship.  However, you can create a doctor finder that starts at the doctor level, instead of the location level.

In that approach, you might present a list of doctors in an interface with the Data Type and Relational Settings > Default Interface For Table option set to Doctors.  Similar to the location table, create a Locations for this Physician field in the doctors table.

Add the field to the doctor's Item Detail Page template, and the list of locations will appear as shown here:

Be sure to modify the locations template found under Data Type & Relational Settings to control the location presentation on the doctor page.

Did this answer your question?