Short answer

As a rule, we don't import asset registers from spreadsheets — but it depends on the quality of the data. Civic.ly needs two things a spreadsheet almost never has: precise locations (latitude/longitude or what3words) and properly itemised assets (one row per physical item). Most council spreadsheets fail both — they group assets into single line items (one row for a whole playground, or "22 benches" on a line), carry no photos, and are often years out of date. So spreadsheets are usually not fit for purpose for import, and the better route is to capture assets in the field by walking the town and village — which doubles as a chance to ground-truth what's actually still there.

Two exceptions where we can import: a council with good location data already in Parish Online or Pear Mapping (we have imported from both), and a genuinely high-quality spreadsheet that is itemised and does carry precise locations — send it over and we'll assess it.

Detail

Why spreadsheets usually don't work:

  • No precise locations. Civic.ly is a mapping platform — every asset sits at a point or area on the map. A spreadsheet typically has a postal address or a free-text location ("Recreation Ground") at best, not the latitude/longitude or what3words coordinate the platform needs to place a pin. Without that, there's nothing to import the asset onto.
  • Not itemised. Most asset registers are grouped, because they were built for an accountant's fixed-asset register, not for field operations. A single line covers a whole playground rather than each swing, slide, and safety surface; "22 benches" sits on one row. Civic.ly works at the level of the individual item that gets inspected, serviced, and has its own history — so a grouped register can't be mapped to individual assets without re-doing the itemisation by hand.
  • No photos. Field capture in Civic.ly is photo-led; spreadsheets carry none.
  • Often out of date. A spreadsheet is only as current as the last time someone physically checked. Councils frequently haven't visited every location to confirm assets are still there, in what condition, or whether new ones have appeared. Importing a stale register just bakes the staleness in.

Why field capture is the better route anyway:

Customers who've built their register by walking the town and village have almost always discovered their old spreadsheet was out of date — assets gone, assets added, conditions changed. So capturing in the field isn't just a workaround for the import limitation; it's a genuine opportunity to ground-truth the whole register at the point of onboarding.

When we can import:

  • Parish Online / Pear Mapping. Councils already holding their asset locations in one of these GIS tools have proper coordinates, so we have imported from them.
  • A genuinely good spreadsheet. If a council does have a well-built register that is itemised down to the individual asset and carries precise locations (lat/long or what3words), it's worth sending over — we'll assess whether it's fit for purpose and, if so, import it. The bar is the two requirements above: precise locations and one row per real item.

Watch-outs

  • Walking the assets is the normal way to start, not a fallback. Almost every council begins with a spreadsheet, and almost every council ends up capturing in the field anyway. Plan for it from the outset rather than treating it as what you do if the import fails, and the register you end up with will be worth more than the one you started with.
  • Send us the spreadsheet before you plan around an import. Whether it can be imported turns entirely on the two things above, precise locations and one row per real item, and that is a judgement we have to make by looking at the file. Do send it over. Just don't build your onboarding schedule around an import until we have confirmed it will work.
  • There is no self-service upload in the web app. Where an import is possible, we run it for you. You won't find a bulk-upload button for asset registers, so if you have a file you think qualifies, send it to us rather than hunting for the screen.