Add locations
Three ways to load Locations into DropAFinder, plus guidance on which to pick when. After this page you’ll have the data backing for any Finder you build.
Pick the right method
| You have… | Use… | Why |
|---|---|---|
| 1–10 locations to enter by hand | Manual entry | Fastest for tiny datasets; no setup. |
| A clean CSV with consistent columns | CSV import | Predictable, sync, no AI involved. |
| A messy CSV, scraped data, or freeform text | AI Location Import | An LLM normalizes addresses, splits fields, and produces clean drafts you review before saving. |
💡 Tip: If your CSV is “mostly clean” and you’re not sure, start with CSV import. If validation fails on rows or addresses don’t geocode, the AI Import is a one-step recovery.
Method 1 — Manual entry
Open Locations from the sidebar and click Add location. Fill in the form:
- Title (required) — the display name visitors see, e.g.,
Downtown Store - Street address (required) — line 1 plus optional lines 2 and 3
- City, State, Postal code, Country (required for geocoding)
- Phone, Website (optional)
- Image (optional) — uploaded directly; rendered at the visitor-facing detail card
- Custom field values — appear if you’ve defined any Custom Fields at the Workspace level
- Tags — free-form labels; either pick existing or create new
🟡 [SCREENSHOT: Add Location form with all required fields populated, the autocomplete suggestions dropdown visible on the address line, and the “Save” action highlighted.]
On save, DropAFinder uses the Workspace’s configured autocomplete provider (Google Places by default, see Autocomplete providers) to resolve the address into latitude/longitude. The Location appears in the list with a coordinate pair populated.
Fixing a wrong geocode
If the autocomplete picks the wrong location (common for ambiguous addresses), open the Location and override the coordinates manually. The override sticks across re-saves.
🔴 [NEEDS CLARIFICATION: Confirm whether manual lat/lng overrides are exposed in the current Location editor UI, or only via API.]
Method 2 — CSV import
For 10s to 1000s of pre-cleaned locations.
Prepare your CSV
DropAFinder is forgiving about column names but strict about content. The minimum your CSV needs:
- A column for the location name (e.g.,
title,name,store_name) - A column for the street address
- Columns for city, state, postal code, country (or one combined
addresscolumn the AI Import would handle better)
Optional columns: phone, website, image URL, and one column per Custom Field you’ve defined.
Run the import
- Go to Locations → Import → CSV
- Upload the file
- Map columns — DropAFinder shows your CSV columns on the left, DropAFinder fields on the right; drag or select to map them
- Validate — rows with missing required fields show as errors; you can either fix the CSV and re-upload, or skip those rows
- Commit — locations are created in bulk; addresses geocode synchronously
🟡 [SCREENSHOT: CSV import wizard at the column-mapping step, with three source CSV columns mapped to DropAFinder fields and one column unmapped.]
CSV import is synchronous — the whole batch processes during the request. For very large CSVs (thousands of rows), this can take a minute or two; the page stays loaded until it completes. For larger or messier data, prefer AI Location Import (next).
CSV gotchas
- Encoding — UTF-8 only. Files saved from Excel default to Windows-1252 and may corrupt accented characters. Save as “CSV UTF-8” from Excel, or open in a text editor to confirm encoding.
- Headers — the first row must contain column headers; data rows start at row 2.
- Quoted fields — wrap any value containing a comma in double quotes.
- Custom Field columns — must match an existing Custom Field definition by name; column names that don’t match are silently ignored.
Method 3 — AI Location Import
For messy data: scraped lists, mixed formats, partial addresses, or anywhere you’d otherwise spend an hour cleaning manually.
How it differs from CSV import
CSV import takes well-structured data and trusts it. AI Location Import takes whatever you give it and produces drafts that you review before any Location is saved. If the AI gets something wrong, you fix it in the review step; nothing reaches your real Locations table until you approve.
The flow
- Go to Locations → Import → AI Import
- Paste text or upload a CSV
- Generate — DropAFinder enqueues an AI job. The Process tray shows progress (this can take a few minutes for large batches).
🟡 [SCREENSHOT: AI Import Batch creation form with a CSV file uploaded and the “Generate” action highlighted. Process tray visible in the corner showing the job in progress.]
- When generation completes, you land on the batch review page. Each row shows what the AI extracted: title, address fields, phone, website. Per-row controls let you:
- Approve as-is
- Edit any field
- Reject (skip this row)
- Apply — approved rows are turned into real Locations; rejected rows are discarded; edited rows persist your changes
🟡 [SCREENSHOT: AI Import batch review page with three drafted locations visible, one being edited inline, and the “Apply” action at the bottom.]
🔴 [NEEDS CLARIFICATION: Which LLM provider backs the AI import (OpenAI / Anthropic / internal). Affects what you can promise customers about data handling and retention.] 🔴 [NEEDS CLARIFICATION: Are there per-plan row limits on AI Import?
subscription_tiermiddleware exists on workspaces but no AI-specific gating found in the codebase digest.]
When the AI gets it wrong
The point of the review step is that you catch this. Common cases:
- Wrong country detected — the AI may default to your account’s country for ambiguous locations. Edit the Country field on each row.
- Phone numbers parsed into the address — happens with very freeform input. Cut from address, paste into phone.
- One row split into two — happens when a single source line described two locations. Reject one, edit the other.
The Process tray and batch review state persist; you can leave the review and come back later.
After importing
Whatever method you used, your Locations now show up in the Locations panel. From here you can:
- Review the list and spot-check geocoding
- Attach Locations to Maps so a Finder can use them
- Add Tags or set Custom Field values in bulk
- Move on to building a Finder
Editing and deleting
- Edit — open any Location to update fields. Re-saving with a changed address re-geocodes.
- Delete — soft semantics depend on the backend (see open question). Practically: a deleted Location disappears from every Finder that references it.
🔴 [NEEDS CLARIFICATION: Soft-delete vs. hard-delete on Location. Audit log captures the action, but undelete UX is not visible. Document the recovery story.]
Where to next
- Group these Locations into Categories: Categories
- Build a Finder backed by your data: Create your account → step 4
- Add structured attributes: Tags and Custom Fields
- Publish: Publish and embed