Short answer

Yes for the bulk of it. Trees are managed as assets — plotted on the map, with photos, status, condition, and free-text notes. Audits, inspections, and outstanding works fit naturally as scheduled inspections and jobs against each tree. The current gap is structured per-tree fields for arb-specific data like the TPO flag, stem diameters, and tree-survey class — those have to live in the asset's description or notes today rather than as their own data columns.

Detail

A typical council tree register has a few categories of data, most of which map cleanly onto Civic.ly today.

What sits well as standard asset data

  • The tree itself is an asset, plotted on the map as a point (single tree) or a polygon (clump / wooded area — see the related Q&A on individual trees vs clumps).
  • Photos attach to the asset as you'd expect.
  • Status (Active / Inactive / Felled) and Condition (Good / Fair / Poor) are first-class fields and feed the dashboard widgets.
  • The council's existing Tree ID can live on the asset's external reference if they want to keep their numbering.
  • Year planted slots into the install date.
  • Species can sit on the asset name. AI auto-classify will usually assign the asset type "Tree" from an uploaded photo.

What sits well as tasks

  • Annual or post-storm inspections are a routine that auto-creates an Inspection per tree on the cadence the council wants.
  • "Last audit" date is recorded automatically when an inspection is completed — no need for a separate field on the asset.
  • Outstanding works (crown lift, deadwood removal, fell-and-replace, etc.) are jobs raised against the tree, each with a cost, a due date, and an assignee. The pipeline view then doubles as the council's outstanding-arb-works tracker, including total spend per tree or per pitch via a task export.

What doesn't have a structured home today

  • TPO yes/no flag.
  • Stem dimensions (single trunk diameter, multi-stem counts and sizes, base measurements).
  • Tree-survey class or category (e.g. BS 5837 categories A/B/C/U).
  • Specific arb defect taxonomies (tight unions, ratio of deadwood, decay class, etc.).

These all sit in the asset's notes field as free text today. That works, but it isn't filterable or reportable. Councils with a mature tree-officer function feel this gap; councils with a lighter touch usually find the notes field enough.

So the honest position is: the core of a tree register works today, and structured tree-specific fields are something we would consider building if enough councils need them. They are not on the roadmap at the moment, so don't plan around them arriving.

Watch-outs

  • There are no custom fields per asset type. You may hear the idea discussed, but it isn't something you can configure today. Free text in the notes field is what you actually get.
  • Coming from a dedicated tree-mapping product? If you use PAUL Arboriculture, Ezytreev, ArbPro or similar, you will have years of structured tree data. The tree records and their locations import cleanly, but the arb-specific columns land as a single block of notes until we build structured fields, so go in expecting that rather than being surprised by it.
  • If you are weighing up replacing your existing tree register, talk to us first. A walkthrough of the product you use today is the quickest way to scope what would migrate cleanly and what wouldn't, and it tells us what is worth building.