Choosing Field Service, scheduling-only, or a custom build

What it does

This is the first fork on any field-work project: install Dynamics 365 Field Service and take the work order model as given, take only Universal Resource Scheduling and hang it off your own table, or build scheduling yourself in Dataverse. Field Service installs URS automatically, so the middle option is not a separate product — it's the decision to skip work orders, incidents, agreements, inventory and the mobile app, and keep the booking engine.

Key facts

URS ships as part of the Field Service install. You don't buy it separately, and you can't install Field Service without it.
Any customisable table can be enabled for scheduling under Resource Scheduling > Settings > Administration > Enable Resource Scheduling for Entities. The table needs its "Can be customized" managed property set to True or it won't appear in the picker.
Enabling a table creates (or reuses) two relationships — a Booking Relationship to Bookable Resource Booking and a Requirement Relationship to Resource Requirement. Take "Create New Relationship" unless you have a very good reason.
Once enabled, the table gets a Book command and a Resource Requirements related grid, and picks up its own scheduling defaults: default booking duration, default booking status, default requirement statuses, whether requirements auto-create for bookings, and whether the schedule board treats times as UTC or local.
Field Service's own contribution over that baseline is the work order lifecycle (six system statuses), incident types, service tasks, products and services on the job, agreements, inventory, RMA/RTV, inspections, and the mobile app.
Field Service is a full Dynamics 365 licence per user, and dispatchers, technicians and back-office staff are licensed differently. The mobile app carries no extra charge on top of it.

When to use / skip

Default to full Field Service. If the work has a customer, an address, a technician who turns up, parts, and something billed or reported afterwards, you'll rebuild eighty per cent of the work order model yourself and do it worse. Enough "we only need scheduling" projects quietly grow incident types, service tasks and a parts list by month four that I treat the request as a scoping smell rather than a requirement.

Scheduling-only URS is right in a narrow band: where the thing being scheduled is not a service visit. Assigning caseworkers to cases, allocating assessors to applications, booking rooms and kit for events, dispatching auditors — these have a resource, a duration and a location, and nothing else in the Field Service model earns its keep. If you're scheduling against Cases and the outcome is a phone call or a desk task, URS on Case is a clean fit and Field Service is dead weight.

The pure custom build is almost never right, and I'd push back hard. People reach for it because the schedule board looks unfamiliar, or because someone has a Gantt control they like. What you're taking on is availability calculation across work hours, time off, capacity and multi-day spans; travel time and geocoding; territory and characteristic matching; and a UI dispatchers use for eight hours a day. The one case I'd concede is where the "schedule" isn't time-and-resource at all — a queue with no calendar, or allocation that is purely rules-based with no dispatcher. If there's no schedule board in the target state, URS isn't buying you anything.

Configuration decisions

Decide whether work orders are your scheduling unit at all, before you touch the org. Retro-fitting work orders onto a URS-on-custom-table design means re-pointing every booking, and bookings carry actuals.
If you go scheduling-only, decide which table is the requirement source and whether requirements are created by the platform or by your own logic. Auto-create is a per-entity setting and it changes what dispatchers see on the board.
Choose your booking status set early. Field Service ships Travelling/In Progress/On Break/Completed and wires them to work order status; a custom table gets whatever you define, and nothing downstream reacts.
Decide territory model up front — resources, requirements and RSO scopes all key off it, and it's the hardest thing to change once dispatchers have learned their boards.
Settle licensing per persona before design. Dispatchers, technicians, and read-only reviewers land on different SKUs, and a "everyone gets full Field Service" assumption will blow the business case.

Gotchas

The Field Service install is not reversible in practice. Uninstalling is documented, but on a live org with data in msdyn_ tables you're looking at a new environment, not an uninstall.
Enabling a custom table for scheduling is easy; unwinding it is not. The relationships persist after deactivation and confuse later solution imports.
Choosing "scheduling only" doesn't reduce your solution footprint. Field Service is still installed, its tables are still there, and its plugins still run.
Work order system statuses cannot be extended. Teams that plan an eight-stage lifecycle discover they need substatuses mapped onto six system statuses, and reporting has to follow the substatus.
If the maps control is removed from the stock work order form, getting it back means XML surgery. Treat form stripping as a one-way door.
URS availability calls have retrieval limits configured per enabled entity. A custom table with a large resource pool and no filtering will return empty-looking results rather than an error.

Consultant notes

Demo the schedule board and the schedule assistant in the first workshop, not the work order form. The board is what wins or loses the "do we need this" argument, and it's the piece nobody can replicate cheaply.
When a client asks for "just the scheduling bit", ask what happens after the technician arrives. If they can answer in detail, they need work orders.
Push back on custom Gantt controls specifically. Offer schedule board tab configuration, custom resource attributes on the board, and filtering instead — it covers most of what people are actually asking for.
Before go-live, check that every persona has a licence that permits what their security role lets them do. License compliance checks in Field Service will flag this eventually, and it's better found in UAT.
Get the "phase two adds work orders" decision recorded in writing. It's the most common cause of a rebuild eighteen months in.

Worth revisiting if Microsoft changes how URS is packaged, or if the licence split between dispatcher and technician moves again.