Functional locations for assets

What it does

A functional location is a place inside a customer site — campus, building, floor, plant room — that assets and work orders can point at. It gives you a hierarchy underneath the service account so a technician gets "Building A, third floor, riser cupboard" rather than just a postal address.

Key facts

Functional locations are created from the service account: Service area > Accounts > open the account > Assets and Locations tab > ellipsis > New location.
Name and Service Address are required. Optional fields include Functional Location Type, Parent Functional Location, Cost center, Open date, Email address and Primary time zone.
Hierarchy is set either by picking Parent Functional Location on the record or by dragging nodes around in the tree on the Assets and Locations tab.
Assets attach to a location from the same tab: select the location, ellipsis, then Add existing asset or New asset. Show assets toggles them into the tree.
Sub-assets can't live in a different location from their parent asset. Move a sub-asset under a parent that's elsewhere and it inherits the new parent's location.
Functional Location Types are a separate setup table (Settings > Functional Location Types) used to classify locations — building, floor, room — and to apply property templates to a group of locations in one go.
Work orders carry a functional location in the Location section of the General tab. If it's blank, the work order falls back to its service address, then to the contact's address.
Each incident on a work order can carry its own functional location, which is how you handle one visit covering plant in two buildings.
Cases pick up a functional location on the case's Field Service tab, and agreements do it through the agreement booking incident, so a location set once flows into the generated work orders.
Filtering functional locations by service account isn't supported in the offline-enabled mobile app. Location hierarchies need a connection to browse properly.

When to use / skip

Use functional locations when a single customer account covers somewhere big enough that the address doesn't tell a technician where to go: hospitals, universities, shopping centres, manufacturing plants, multi-tenant office estates, anything with a plant room. They're also the right answer when the client wants asset counts per building for capital planning.

Skip them for single-site, one-address customers. A functional location that duplicates the service account name adds a lookup, a data-quality problem and a training slide for nothing. Plenty of good Field Service implementations never turn them on, and you can add them later for the customers that need them without touching the ones that don't — the field is optional everywhere it appears.

Be careful about the middle case: a client with a handful of large customers and a long tail of small ones. Model locations only for the large accounts and accept an inconsistent tree rather than forcing a fake hierarchy on everyone.

Configuration decisions

How many levels the tree actually needs. Campus > building > floor > room is four clicks per asset for whoever maintains the register; two levels is often enough and much more likely to survive.
Whether functional location types are a real taxonomy (used for property templates and reporting) or just labels. If you're not going to hang templates off them, keep the list to a handful.
Whether the location or the asset is the thing work orders reference. Both are possible, and letting each dispatcher choose is how you end up with unusable reporting.
Who maintains the tree — the client's facilities team, your support desk, or technicians on site — and whether that role can even see the Assets and Locations tab.
Whether Cost center on the location is being used for chargeback, in which case it needs a source of truth and a sync, not free text.
What the mobile experience looks like given the offline filtering limitation: whether technicians pick locations at all, or just read the one stamped on the booking.

Gotchas

Locations are created in the context of a service account but the hierarchy can span accounts, so it's entirely possible to build a tree that half the users can't see because of their account access. Check this with real security roles, not as a system administrator.
The silent inheritance of a parent's location by a sub-asset is the classic support ticket: someone reparents a component and the location on the child changes without a prompt.
The offline mobile limitation bites in exactly the buildings you built locations for — basements, plant rooms, lift shafts. Assume the tree is unavailable there and make sure the booking itself carries enough detail.
The work order location fallback chain (functional location, then service address, then contact address) means a blank location doesn't look broken. It looks fine and quietly sends the technician to the head office address on the account.
Deleting a location that assets still point to is not a tidy-up operation. Reparent the assets first.
Property templates applied through a location type only reach locations that carry that type. Locations created before you defined the type won't be backfilled.

Consultant notes

Get the client to draw their site hierarchy on paper before you configure anything. If two people in the room disagree about whether "Block C" is a building or a wing, you've found the real scoping conversation.
Demo the tree with a genuine customer site loaded, not a two-node sample. The value only shows up at the fourth or fifth node.
Push back on modelling locations for every account "for consistency". Consistency here costs data maintenance forever and buys nothing for small customers.
Before go-live, walk one technician through finding an asset by location on mobile, offline, in a building with no signal. That test decides whether the design holds.
If the client is coming from Supply Chain Management's asset management module, be explicit that these are different functional location implementations — the concept transfers, the configuration does not.

Worth revisiting if offline support for functional location filtering improves, or if the client takes on a large multi-building customer.