Stores and locations

A store is the thing being protected. Units attach to stores, alerts are about stores, and compliance records are per store.

The words are yours: an organization admin can rename this whole concept in Settings → Terminology ("Restaurants & QCCs", "Facilities", …) and switch the Regions grouping level off for businesses that don't organize that way. Hiding a level changes only what is shown — existing regions and member territories keep working untouched. The same Settings section also chooses which heat metric the dashboards show (WBGT, Heat Index, or both) — see "Heat index vs WBGT".

Stores are the backbone. Almost everything else in the product refers to them: a unit protects a store, a person's territory is a set of stores, an alert names a store, and an OSHA record is per store.

Field	Why it matters
Name	What appears in alert messages. Make it what your team calls the place.
Store number	Your own identifier. This is the key your people search by and the one that matches your other systems.
Address	Turned into map coordinates automatically when you save. Places the store on the map, gives every unit assigned there its map pin and weather forecast, and lets a cellular unit's reported position be checked against where you think it is
Operating hours	When the building is occupied. Alerts outside these hours are held until it opens.

Store number is worth filling in even though it's optional. At any real scale it becomes the thing everyone types into search, and it's how a bulk import matches rows to stores you already have.

The page is organised as collapsible sections — Stores, HeatAlert Connect units, then Set-up — each with a one-line summary (how many stores lack a sensor or a contact, how many sensors are unassigned), so at hundreds of stores you scan the summaries and open only the section you're working in. The Stores section also supports selecting many stores at once to apply a region or market to all of them.

Related