Acumatica Field Service — Dispatch Board

The dispatch board — Acumatica calls it the Calendar Board — is where the Field Service module either wins or loses the room. Back-office staff will forgive clunky setup screens; a dispatcher staring at the board eight hours a day will not. I've configured field service for an equipment maintenance company and an HVAC-adjacent contractor, and in both cases the board configuration and the discipline around appointment statuses mattered more than any other module setting.

The object model under the board

Understanding the board means understanding three documents. A service order (FS300100) is the commitment — customer, location, problem, estimated services and inventory. An appointment (FS300200) is a scheduled visit against that order: one order can have many appointments (initial visit, return with parts). The board schedules appointments, assigning them to staff (employees flagged as service personnel, with skills, licenses and service areas) on a timeline. Everything you drag on the board is an appointment; everything unscheduled in the side panel is an order or appointment awaiting a slot.

Board setup that dispatchers actually thank you for

• Filter the staff list hard. The board renders a row (or column) per staff member. Fifty rows is unusable; configure branch and service-area filters so a dispatcher sees their crew only.
• Color by status, not by service type. The board supports color-coding; the question a dispatcher asks fifty times a day is "who's running late," not "which of these is a boiler job." Map colors to the appointment status flow — scheduled, en route, in progress, completed, paused — and anomalies jump out.
• Skills and geographic zones as soft constraints. Acumatica can restrict or warn when you assign an appointment to staff missing a required skill or outside the service area. Configure them as warnings, not blocks — real dispatching is full of justified exceptions, and hard blocks teach dispatchers to stop maintaining skills data.
• Appointment duration defaults from the service. Estimated durations on service non-stock items make dragged appointments land with realistic widths. Boards where everything is a one-hour block drift from reality by noon.

The status flow and its automation

Appointments run a workflow: Not Started → En Route → In Process → Completed → Closed (with Paused branches). Each transition timestamps — that's where actual-vs-estimated duration reporting comes from, and it's what makes payroll-adjacent questions answerable. Business events on these transitions do useful work with zero code: notify the customer by SMS/email when the tech goes en route, alert the dispatcher when an appointment sits In Process ninety minutes past its estimated duration, or when a scheduled appointment hasn't gone en route fifteen minutes after start time.

For deeper logic, appointment DACs extend like anything else. One client needed appointments over four hours to require a second tech — a RowPersisting validation on the appointment graph extension:

public class AppointmentEntryExt : PXGraphExtension<AppointmentEntry>
{
    protected virtual void _(Events.RowPersisting<FSAppointment> e)
    {
        var row = e.Row;
        if (row == null || row.EstimatedDurationTotal <= 240) return;

        int staffCount = Base.AppointmentServiceEmployees
            .Select().Count;
        if (staffCount < 2)
            PXUIFieldAttribute.SetWarning<FSAppointment.estimatedDurationTotal>(
                e.Cache, row,
                "Appointments over 4 hours normally require two staff members.");
    }
}

Routes and the map view

If you license the routes functionality, the board pairs with map-based views — appointments plotted by service address, and route optimization to sequence a day's visits per vehicle. My experience: the map view earns its keep immediately for density visualization (a dispatcher seeing three jobs in the same suburb schedules them consecutively without any algorithm), while full route optimization requires clean address data and realistic durations before its output beats a competent human. Geocode validation on customer locations is the unglamorous prerequisite — garbage coordinates put appointments in the ocean.

From appointment to invoice

The board's downstream payoff is billing. Completed appointments carry actual services, parts consumed, and time; the billing cycle configuration (per customer) decides whether invoices generate per appointment, per service order, or batched. Make sure techs close appointments with accurate lines on the day — the single biggest field-service billing failure I've seen is appointments left In Process for a week, invisible to the billing run, discovered when the month's revenue comes up short.

Wrapping up

Treat the calendar board as the dispatcher's cockpit: few rows, status colors, realistic durations, warnings over blocks. Wire business events to the status flow for customer notifications and exception alerts, keep the mobile flow so simple that techs actually feed the board live data, and enforce same-day appointment closure so billing sees reality. The module's mechanics are solid — the implementation work is making the humans and the board tell each other the truth.