Short answer

Split a parent asset (a building, a play area, a vehicle) into individual component assets whenever the components (a) need their own audit trail — a record of which specific item was checked, when it failed, when it was repaired or replaced — or (b) need their own data fields captured against them (make, model, supplier, installation date, warranty, serial number). A useful shorthand that covers both: if it gets its own inspection or test, it gets its own asset. That single rule catches PAT-testable electricals, fire alarms, emergency lighting, lifts, boilers, and legionella points. You don't have to do this all at once — start fairly high-level and add detail incrementally as your inspection routines mature.

A common misconception: the reason to split isn't that the platform can't attach multiple inspection cadences to one asset — it can. You can run a weekly cleaning routine and an annual EICR routine against the same "Pavilion" asset. The reason to split is that doing so collapses every record of every check into one place against the parent, with no per-item history.

Detail

This is a different question from "should I split an area into two side-by-side assets" (which is about geographic splitting at the same level — see When should I split an area into multiple assets vs treat it as one?). This entry is about vertical decomposition of a single compound asset — a building broken into its boiler / doors / fire alarm, a play area broken into its equipment and surfaces, a vehicle broken into its MOT-checkable parts.

There are two reasons to do it, and either one alone is enough.

1. A per-item audit trail

A building looks like one thing to an inspector arriving at the gate, but the work that gets done to it varies enormously:

  • Structure itself. Building revaluation every 3–5 years, insurance renewal yearly.
  • Fire alarm. Weekly call-point test, with annual certified inspection. Regulatory.
  • Emergency lighting. Monthly function test, annual duration test. Regulatory.
  • Legionella. Per water source on its own rhythm — typically monthly outlet flushes and annual risk assessment review.
  • Boiler / heating system. Annual gas service. Replacement every 10–15 years.
  • Routine cleaning. Daily or weekly, contractor-dependent.
  • Doors. Periodic inspection and occasional repair.
  • Roof. Long cycle — inspect every few years, react to leaks.

The platform will happily let you attach all of those routines to a single "Pavilion" asset — there's no one-routine-per-asset limit. The problem isn't that the rhythms collide; it's that every record of every check then sits against the parent, and you lose the per-item audit trail.

A "Weekly Fire Extinguisher Check" routine pinned to the building tells you that the extinguishers were checked — it doesn't tell you which extinguisher, which one failed, or when that specific unit was last replaced. A "Monthly Emergency Light Test" pinned to the building tells you a test happened, not which luminaire #4 had a flat battery and got swapped out. Split, every check, defect, completion note and replacement lives against the specific item — and three years later, when you need to show an inspector when extinguisher #3 was last serviced and what model replaced it, the record is in one place.

That's the operational case for splitting. The mechanical "you couldn't attach those routines otherwise" argument is wrong — you can; you just lose the granularity that makes the records useful.

2. Different data to capture

This is the reason that is most often overlooked, and it stands on its own — even where the work rhythm doesn't differ, the data captured against the component usually does:

  • Boiler. Make, model, serial number, installation date, service contract, warranty, manual.
  • Fire alarm panel. Manufacturer, model, software version, commissioning certificate, last service date.
  • Fire extinguisher. Type (CO2 / foam / water), service interval, expiry date.
  • Emergency-light battery pack. Manufacturer, install date, expected battery life.
  • Door. Leaf type, fire rating, access-control system, glazing.
  • Electrical appliance. Make, model, PAT test date, electrical class.

None of that fits cleanly on a parent "Building" record alongside the structure's own attributes (square footage, insurance value, last revaluation, AGAR flag). Splitting puts each piece of detail with the right thing — and means a future replacement (a new boiler) updates one record cleanly, not a freeform note appended inside the parent.

3. The "own inspection → own asset" shorthand

A useful single rule that catches almost every case worth splitting: if a component gets its own inspection or its own test, it should be its own asset.

This is the rule that drives PAT-testable items being listed individually — every kettle, microwave, monitor, lamp gets its own line on the register because PAT testing forces it. The same logic applies to:

  • Fire alarms (weekly test).
  • Emergency lighting (monthly function, annual duration).
  • Lifts (statutory thorough examination).
  • Boilers and gas appliances (annual gas safety).
  • Pressure systems (written scheme of examination).
  • Legionella outlets (monitoring schedule).
  • Playground equipment (RoSPA inspection).
  • Play-area safety surfaces (RoSPA line-item, separate from the equipment above it).

If you only remember one heuristic, this is the one.

Starting high-level and adding detail over time

The single most common reason councils freeze on this question is overwhelm — a building has dozens of components, you can't capture them all in a week, where do you start?

The answer that works: start fairly high-level and add detail incrementally. The asset register is meant to grow with you, not be perfect on day one.

Two sequencing patterns both work:

  • Top-down — building first, then split inside. Begin with "Men's Toilets" as a single asset. In a later pass, when you're ready to formalise cleaning routines or capture fixtures for insurance purposes, split out each cubicle, sink, and hand-dryer.
  • Component-first — building plus the regulated bits. Keep the building as one parent asset, but immediately split out every fire alarm, emergency light, and PAT-testable item, because those carry inspection rhythms you want to formalise straight away. Add the cubicles and sinks and hand-dryers later.

The route to pick depends on what's driving the work. If a regulatory inspection is the urgent prompt (fire alarm test, PAT test, RoSPA), lead with components. If a basic register for AGAR / insurance is the urgent prompt, lead with parent assets and split later as routines come on-stream.

Worked examples

  • Pavilion with a function room. Parent: "Recreation Ground Pavilion" (carries structural attributes, insurance value, revaluation history). Children: boiler, fire alarm panel, each emergency light, water heater, each fire extinguisher, each PAT-testable appliance, the roller shutter at the entrance, each external door.
  • Public toilet block. Parent: "Men's Toilets" (carries the cleaning schedule and structural data). Children added later: each WC cubicle, each sink, each hand dryer, the lock system. Start as one; expand when cleaning routines or fixture-replacement work pushes you to.
  • Play area. Parent: "Recreation Ground Play Area" drawn as a mapped polygon so children inherit it as a location tag. Children: each item of play equipment as its own asset, the safety surface under each item as its own asset (RoSPA-separate from the equipment above), any benches and bins inside the perimeter.
  • Council-owned van. Parent: "Highways Van (Reg ABC123)" (insurance, MOT date, service history at vehicle level). Children worth splitting only when the work differs — e.g. if the van has a tail-lift on its own LOLER inspection cycle, the tail-lift becomes its own asset.

Watch-outs

  • Naming convention — don't always repeat the parent's name. If the parent is drawn as a mapped polygon (a play area, a park, a pavilion footprint), children inside it inherit the parent's location tag automatically. There's no need to repeat the parent's name in the child's name: "Slide Surfacing" is enough; "Recreation Ground Play Area — Slide Surfacing" is redundant. See How do map areas work, and how do location tags get inherited?.

Exception: when two sibling assets aren't inside a mapped area but want to group together in the asset list (e.g. a play area's grass and the bank around it, when neither has its own polygon), a shared prefix helps. See When should I split an area into multiple assets vs treat it as one? for the sibling-prefix pattern.

  • Don't split for the sake of it. Two doors that are inspected, repaired and replaced on the same schedule, by the same contractor, in the same pass, with no per-door data worth capturing — those can stay as one asset, or as "External Doors (×4)" if you want a count visible.

  • Cost data being patchy is not a reason to delay splitting. Most councils on the platform have £0 on most value fields. Fill them in opportunistically — insurance renewal, replacement quote, year-end AGAR — not upfront. Don't let cost-data hunting hold up the structural decisions.

  • The asset-type catalogue is finite. Civic.ly's global type list includes Door, Window, Boiler, Heating System, Pavilion, Safety Surface and many more, but not every electrical sub-type or every regulated component. Where there's no exact type, pick the closest and use a descriptive name; the AssetTypeFactory team is gradually filling gaps.

  • Inheritance and bulk-update gotchas. When a parent is a mapped polygon, children created inside it inherit the location tag automatically. Children created before the area was drawn won't — see How do map areas work, and how do location tags get inherited? for the backfill workflow (drag-and-save each child to retrigger inheritance).