A purchased voter file — or an export from your party, or from a previous campaign — usually arrives with the electoral areas already filled in on every row: the congressional district, both legislative districts, the precinct. pplCRM reads those columns directly during a households import. Nothing is looked up, no outlines are needed, and it costs nothing. If you have a file like that, this is by far the fastest way to get electoral geography into the workspace, and it is worth doing before you go hunting for map files.
Column names that are recognised
On the Map columns step the wizard guesses from your header row. The guess ignores case, spaces and punctuation, so Congressional District, congressional_district and CONGRESSIONALDISTRICT are all the same header as far as it is concerned.
- District and Riding — a seat area.
- Ward — a seat area in most places, a voting subdivision in Massachusetts. You say which when the set is created; the column name never decides it.
- Precinct, Poll and Polling division — a voting subdivision. New York files that say Election district mean the same thing.
- CD and Congressional district — the US federal seat area.
- LD and Legislative district — a US state seat area. If your file has separate upper-chamber and lower-chamber columns, map each one; they are different maps and they are kept apart.
A column named something we do not recognise is not lost. Every column on the Map columns step has a field picker, so choose the right field yourself and it imports exactly the same way. Anything you leave unmapped shows a “Skipped” chip and is left out, as always.
What the import creates
Each mapped column becomes one boundary set in your workspace — a named map with a declared role — and each row’s value becomes that household’s area name inside it. A file carrying CD, LD and Precinct columns produces three sets and three area names per household, and none of them overwrites another. See Boundary maps.
What you get from imported names, immediately: filter and sort Households by area, count doors per area, build a smart list like “everyone in precinct 12”, and export by area. Turf cutting uses these areas as its boundaries too, but it also needs each door’s coordinates — see the geocoding note below.
What you do not get: an outline. There is no shape to display, and — more importantly — nothing to place a new address into. A household typed in by hand next week, or arriving from a web form, has no value for that set until you import one for it or add the real map by upload or by drawing. If addresses keep arriving after the initial load, plan on getting the actual map eventually.
Tidy the column before you import, not after
Area names are matched as plain text, so Ward 3, WARD 3 and 3 are three different areas. A file that spells the same ward two ways produces two areas where you wanted one. Five minutes in the spreadsheet beforehand saves a merge afterwards. The rest of the wizard behaves exactly as Import from CSV describes — Upload, Map columns, Review, Import, and nothing written until the last step. District columns ride along with an ordinary households import; there is no separate import type for them.
These columns trigger no geocoding
Reading an area name out of a column is not an address lookup. If the rows are also brand-new addresses, those addresses still need coordinates before map pins, turf cutting and delivery routing will work, and that part is metered — see Geocoding, boundary matching, and what each costs. The area names themselves are usable the moment the import finishes. 