Oracle Field Service Work Order and Activity Management
Work Order and Activity Management
This domain tests the day-to-day object model: work orders group activities, and activities are the schedulable units. Expect activity types, statuses, links, service windows, required inventory, forms, resolution codes, and mass updates.
Core rules
- A work order is a container; an activity is what gets routed, dispatched, started, and completed. One work order can hold multiple activities.
- Activity statuses follow a status flow (for example pending, started, completed, cancelled, not done). Work order status is separate and may be derived.
- Activity links create dependencies such as finish-to-start; the successor cannot start until the predecessor completes.
- Required inventory on the activity type reserves or consumes parts; availability affects completion.
- Forms capture field data; resolution codes and not done reasons close work with a reason.
- Mass update changes many activities at once, but only fields allowed by the activity type and status.
Worked example
A work order contains Inspect and Repair. Repair is linked finish-to-start to Inspect, and the Repair activity type requires a compressor. The dispatcher schedules Inspect in the 08:00-10:00 window and Repair in 10:00-12:00. If Inspect is not done, Repair cannot start; the link enforces the dependency. If the compressor is unavailable, the activity can still be scheduled but completion may require inventory or a not-done reason. The reasoning: the link protects process order, while inventory protects the physical task.
Traps
Confusing work order status with activity status; reversing link direction; cancelling a parent without handling children; assuming required inventory is automatically reserved; ignoring time zone on service windows; mass-updating fields that are read-only in the current status.