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.

Frame it on a call as: the core is there today, and structured tree-specific fields are something we'd consider building if it becomes a priority across customers. Don't promise — these aren't on the roadmap.

Watch-outs

  • Don't oversell on "custom fields per asset type" — the underlying custom-values table exists in the schema but isn't surfaced as configurable per-type fields in the UI. Free text in the notes is the user-visible reality.
  • Larger councils with an existing dedicated tree-mapping product (PAUL Arboriculture, Ezytreev, ArbPro, etc.) will have years of structured tree data to migrate. The tree records and their locations import cleanly, but the arb-specific columns currently land as a single notes blob until we build structured fields. Flag this honestly up front.
  • If a council asks specifically about replacing their existing tree-register product, ask for a Zoom walkthrough of the product they use today — both to scope the migration and to surface what's worth us building.