You can build a small store locator from Airtable by keeping approved business locations in a table and displaying their coordinates in a miniExtensions map. Add useful categories and a list alternative so visitors can find a suitable branch, read its address, and check its published contact details. The important work is maintaining accurate location records, not simply putting pins on a map.

This example is for a fictional retailer, Cedar Supply, with twelve branches. Its operations coordinator maintains branch details; a marketing reviewer approves public information; website visitors browse the published locator. The proposed workflow uses manual review and a small public dataset. It does not assume automatic geocoding, route planning, real-time opening status, or live stock availability.

Decide what a visitor needs to find

Cedar Supply customers need to distinguish collection counters from full-service shops. A visitor looking for an order pickup should not have to open every pin to find a suitable location. Give each location a clear name, service category, address, and contact number. Add an ordinary description of opening hours, with a date showing when staff last checked them.

Define the expected outcome narrowly: someone can find a published branch with the service they need and contact it before visiting. A point on the map does not demonstrate that a branch is currently open, accessible by a particular route, or able to fulfill an order.

Create a public Locations table

Use a dedicated table containing only information intended for public display. Keep staff-only operational notes and customer records elsewhere. For this example, add these Airtable fields:

  • Location name: single line text and primary field, such as Cedar Supply North.
  • Public address: long text containing the visitor-facing address.
  • Latitude and Longitude: number fields with sufficient decimal precision for the intended location.
  • Services: multiple select, with Collection counter and Full-service shop as example choices.
  • Region: single select with the areas your visitors recognize.
  • Opening hours: long text, maintained by the coordinator.
  • Public phone: phone number; Branch website: URL if a useful branch page exists.
  • Public status: single select with Draft, Approved, and Withdrawn.
  • Details checked on: date.

These field names and categories are a suggested data design, not a built-in store-locator template. Start with three fictional records while configuring the extension. Include one collection counter, one full-service shop, and one draft location with missing coordinates. Do not publish the fictional example as a real branch directory.

Verify coordinates before approving a location

The map needs latitude and longitude rather than address text. A street address that looks complete is therefore not enough. The map input documentation confirms this requirement and describes a separate address-to-coordinate automation.

For the first version, have staff enter and check coordinates manually using a reliable location source. Confirm the pin represents the branch entrance or other suitable public point. Check latitude and longitude have not been swapped, and compare the result with the address. Keep the missing-coordinate record in Draft until someone resolves it.

If you later introduce geocoding, treat it as a separate configured process with its own provider requirements and review. An automatically generated coordinate can still refer to the wrong building or a broad area. Approval should follow a location check, rather than happen merely because two numeric fields are populated.

Configure the miniExtensions map

Connect the Airtable base and create the appropriate miniExtensions extension for a public map. The official map setup tutorial describes selecting Map View during creation, selecting the table containing coordinates, and mapping the latitude and longitude fields. It also requires a Google Maps API key in the workspace.

Have an authorized workspace owner or administrator handle that provider setup. Review the provider’s current account, usage, and billing requirements before relying on the map; this workflow does not make a pricing assumption. The API key documentation explains the workspace configuration and who can manage keys. Never put a key in an Airtable location record or a visitor-facing instruction.

For an existing extension, the documented route is Portal Tables, select the table, then Views and Default View Settings. Set View Type to Map and select the two coordinate fields. Review the view-type guide before configuring custom views, because defaults and view-specific overrides are different settings.

Publish a deliberately limited selection

Create an Airtable view for locations whose Public status is Approved. Select that view for the locator, then inspect what a visitor can actually see through every available table and view. A convenient starting view is not a reason to leave drafts, withdrawn branches, or internal information accessible elsewhere.

Keep this locator read-only for visitors. In the table’s Create & Expand Records settings, disable creating records. Review the detail form and any alternate grid view so visitors cannot edit branch details or delete records. The record creation and editing guide explains where child-form controls live. If you offer record expansion for addresses and hours, check those displayed fields are configured appropriately rather than assuming the map is automatically read-only.

Map views automatically load additional pages of records matching the view filters. Check the displayed coverage against your approved Locations view, including locations beyond the first page, before sharing the locator. Keep the intended geographic and service scope clear to visitors.

Add filters that answer real visitor questions

Services and Region make more useful filters than internal branch codes. The filter configuration guide places these controls under the table’s User Actions section. Enable the Filter button and, where useful, Dropdown filters, then choose the relevant single- or multiple-select fields. Check custom-view overrides as well.

For Cedar Supply, a visitor selects Collection counter and the relevant region. Give the locator an explanatory title such as Find a collection counter or shop. Keep the visible options small enough to understand. A location tagged with several services can match a service choice; test the actual selection behavior rather than implying a more sophisticated search engine.

Consider a list view alongside the map for people who prefer scanning addresses and contact details. Configure and verify that alternative separately. A map is a useful way to browse locations, but should not be the only place a visitor can obtain the branch information needed to make a decision.

Make changes through a review handoff

When Cedar Supply opens a new counter, the coordinator creates a Draft location, enters its public details, and checks its coordinates. The reviewer confirms the published description and changes Public status to Approved. For a temporary closure, the team decides whether to withdraw the location or clearly describe the temporary situation. Keep that decision with the staff responsible for branch information.

Check the visitor-facing result after the change. If hours are corrected in Airtable, verify the displayed location shows the new hours. If a branch is withdrawn, check its absence in the map and every alternate view. These are proposed acceptance checks; this article does not claim that a live locator has been configured or tested.

Test the edge cases before sharing

  • Confirm each approved sample pin corresponds to the intended address and the coordinates are mapped in the correct order.
  • Check the draft record with missing coordinates is excluded, rather than relying on how an incomplete pin happens to render.
  • Verify service and region filters, then clear them and check the complete intended set. Returning visitors may retain browser-saved filters.
  • Open the locator on a phone and confirm useful address and contact information remains easy to reach.
  • Try every exposed create, edit, and delete path with sample records; remove unintended mutation paths before publication.
  • Check the provider setup, displayed record count, and alternate list coverage.

This approach suits a small, maintained location directory whose primary job is helping visitors find and contact an appropriate branch. For turn-by-turn directions, nearest-store distance ranking, live stock, or a larger location network, evaluate those requirements separately. A dependable locator starts with a clear public dataset and a named owner who keeps it accurate.