Acumatica Field Service — Extension Patterns

Field Service (FS) is one of the more operationally complex Acumatica modules because it coordinates people, equipment, and scheduling in near-real-time, on top of the same financial core everything else uses. Extension work here tends to concentrate around scheduling rules and equipment/asset tracking rather than the accounting side, which mostly just consumes what the service order produces.

Core DACs and screens

A service order is FSServiceOrder, with appointments (the actual scheduled visits) on FSAppointment. Order types configure behavior per FSSrvOrdType. The Schedule Board is the visual scheduling surface, backed by its own graph, while service order entry itself runs through ServiceOrderEntry (naming varies slightly by version). Equipment being serviced is tracked against installed customer equipment records tied back to inventory items.

Extension points

Custom scheduling constraints — a technician's certification required for certain equipment types, a geographic zone restriction, a minimum gap between appointments for travel time — are typically implemented as validation on appointment assignment, either in a graph extension on the appointment entry point or as a rule evaluated by the Schedule Board's assignment logic, depending on version and whether the constraint needs to affect what the dispatcher sees versus what's simply blocked at save.

A realistic scenario: certification-gated assignment

A common FS customization: certain service order types require a technician holding a specific certification (electrical, refrigerant handling), and the system should prevent an uncertified technician from being assigned rather than relying on the dispatcher to remember.

public class ServiceOrderEntry_CertificationGate_Extension : PXGraphExtension<ServiceOrderEntry>
{
    protected virtual void FSAppointment_OwnerID_FieldVerifying(PXCache sender, PXFieldVerifyingEventArgs e)
    {
        var appt = (FSAppointment)e.Row;
        if (appt == null || e.NewValue == null) return;

        int technicianID = (int)e.NewValue;
        string requiredCert = OrderTypeRequiredCertification(appt.SrvOrdType);
        if (!string.IsNullOrEmpty(requiredCert) && !TechnicianHasCertification(technicianID, requiredCert))
        {
            e.Cancel = true;
            throw new PXSetPropertyException("This technician is not certified for the required work type on this order.");
        }
    }
}

Blocking at FieldVerifying rather than RowPersisting stops the invalid assignment before it's even committed to the UI state, which is the better user experience for a dispatcher working quickly through a schedule board — they get immediate feedback instead of a save-time error after they've moved on to the next assignment.

Equipment and warranty tracking

Customizations tracking equipment warranty status or service history against a specific serialized item usually extend the installed-equipment record with custom fields (warranty expiration, last service date) and validation on the service order that warns or blocks work outside warranty terms without an approved billing arrangement. This is a lower-risk category than scheduling logic since it doesn't affect dispatch in real time.

Testing considerations

Test scheduling constraints against the actual Schedule Board interaction, not just by saving an appointment programmatically — drag-and-drop assignment on the board can bypass validation paths that only fire on a specific save sequence, and a rule that works when tested through the API can still be circumvented through the board UI if it's hooked at the wrong layer.

Wrapping up

Field Service extensions succeed by identifying whether a requirement belongs to the appointment data model or to the Schedule Board's interactive layer — they're different surfaces with different extension mechanisms, and confusing the two is the most common way an FS customization looks complete in testing and fails in daily dispatch use.