NextGen FSM
2026 Wave Two 2026 Wave Three 2026 Wave One
2026 Wave Two 2026 Wave Three 2026 Wave One

Configure outcomes

Audience: Administrators and dispatchers

When a field technician finishes a job, they explain what happened onsite and debrief the work order (WO). When a technician debriefs a WO, the system can close the WO, generate a follow-up visit, or flag the record for manual review. To ensure this field data triggers the correct system actions, the platform divides outcomes into outcome causes, outcome cause types, and outcome classes:

Element

User

Description

Outcome cause

Field technicians

The exact, real-world reason selected on the mobile app to debrief the WO. For example,

  • "Meter Replaced"

  • "Customer absent"

  • "Missing parts"

Outcome cause type

The system

The category that groups similar causes together and tells the system what to do if the intervention was a success or a failure: 

  • Success: The WO closes. 

  • Failure: Reschedule the WO.

Outcome class

Dispatchers and planners

A background scheduling rule that determines the initial validation status of the debriefing. It overrides default settings to decide if the debrief requires manual dispatcher review or can be auto-approved.

Understand how outcome tiers work together

Consider what happens when a technician arrives at a site, but they cannot access the facility:

  1. On their mobile app, the technician selects "Customer absent" as the outcome cause.

  2. The system knows "Customer absent" belongs to the “Failure” outcome cause. 

    • The WO cannot be technically closed and must return to a schedulable state.

  3. The system checks the outcome class. 

    • Since this is a failed visit, the outcome class rule flags the debriefing as "Requires manual validation” and overrides standard auto-approval.

    • The dispatcher receives an alert to review the notes before they dispatch a technician for another visit.

Correct outcome configuration ensures field technicians have clear options, the system processes statuses accurately, and dispatchers only validate important exceptions.

What’s next