Oracle Field Service Implementation Professional cheat sheet

Configuration hierarchy: instance → resource types, work order types, service request types, activity types, and properties; changes to types flow to every record using them, so clone rather than edit a type already in production use.

User types control screen and feature access for the application UI; resource types control what a field resource can do and which activity types can be assigned to them - they are separate objects and both must be set.

Custom properties are typed (integer, string, date/time, enum, boolean) and scoped per entity: resource, activity, work order, inventory, and service request properties are distinct namespaces.

Enumeration properties reference a named list of values; the list is maintained centrally, so adding a value propagates to all properties bound to that list without per-record edits.

Screen configuration (application screens / message scenarios) determines which properties appear on the resource's mobile or browser UI; a property not exposed on a screen is invisible to the field resource even if populated.

Business rules and message scenarios trigger on defined events (activity created, moved, completed, resource changed); a rule's condition is evaluated at event time, not continuously, so ordering of rules matters.

The configuration sandbox / test instance is where type and property changes are validated before promotion; configuration is not versioned automatically, so export or document changes before promoting.

Filters and quotas limit which activities a resource can receive; filters are evaluated at assignment time and exclude candidates, while quotas cap a resource's load by activity type or property value.

Plug-in and integration user accounts are configured as separate users with their own permissions; API calls authenticate as a user, so the account's user type governs what the integration can read or write.

Resource capacity is expressed as work time per day plus work zones and work skills; routing only considers resources whose work zone covers the activity's location and whose skills match the activity's required skills.

Work time is defined per resource per day (calendar-based), and capacity planning compares total required minutes of activities against available work time - overtime and travel time must be modeled explicitly.

Work zones are hierarchical: a parent zone includes its child zones, so assigning a resource to a parent zone makes it eligible for activities anywhere beneath it; overlapping zones create ambiguity resolved by routing rules.

Work skills have a rating (typically 1–10) and a ratio; the routing engine can require a minimum rating, and skill ratio influences how much of the resource's day the skill consumes.

Routing plans run on a schedule (not continuously) and may be scoped to a bucket, a resource group, or a time window; a plan run assigns activities but does not dispatch them - dispatching is a separate step.

Routing options control whether the engine optimizes travel time, priority, or due-date compliance, and whether it can reassign already-assigned activities; reassignment of in-progress activities is normally blocked.

Non-scheduled activities (bucket activities) are unassigned work waiting for routing; scheduled activities have a resource and time slot, and a routing run moves work from bucket to scheduled.

Resource calendars, shifts, and time-off entries reduce available capacity; a resource with no shift on a day is not a routing candidate even if skills and zones match.

Crews and multi-resource activities require all member resources to be available for the full activity duration; partial availability disqualifies the crew from the assignment.

Work order is the customer-facing container; activity is the schedulable unit assigned to a resource. One work order can hold multiple activities (for example, install plus follow-up inspection), and activity status drives work order status.

Activity statuses typically progress from pending → started/en route → completed, with a not-done or cancelled branch; status transitions are governed by the activity type's status model and cannot be skipped arbitrarily.

Activity types define duration, required skills, required inventory, and which properties are mandatory; changing an activity type's duration affects newly created activities, not already-scheduled ones.

Service request types capture the intake form for a customer request; converting a service request creates a work order and activities, and the mapping between request properties and work order properties is configured.

Required inventory on an activity type reserves or consumes inventory when the activity is scheduled or completed; insufficient inventory can block completion depending on configuration.

Activity links (predecessor/successor, same-resource, same-time) constrain routing: a successor cannot be scheduled before its predecessor completes, and same-time links force simultaneous assignment.

Time slots and time windows constrain scheduling; the routing engine must place the activity inside the window, and a missed window produces a late activity that routing may flag but not always fix on the next run.

Mass update and activity search allow bulk status or property changes; bulk operations bypass some business rules, so validate rule-dependent fields after a mass update.

The core integration surface is the REST API (outbound/inbound) plus the message queue for asynchronous events; outbound messages are delivered to a configured endpoint and retried on failure, so endpoints must be idempotent.

Authentication for integrations uses a configured user with an API client; tokens are issued per client and the user's permissions bound what the integration can access - there is no separate 'integration superuser'.

Inbound data uses the same object model as the UI: work orders, activities, resources, inventory, and properties; property values must match the property's declared type or the record is rejected.

Outbound message scenarios are configured per event and per recipient; the payload is a template, so field selection is explicit - adding a property to the object does not add it to existing messages.

Data import/export (CSV or bulk load) is used for initial loads and periodic syncs; imports are validated against required fields and referential integrity, and failed rows are reported rather than silently dropped.

Idempotency and duplicate prevention rely on external IDs: supply a stable external identifier on create so retries update rather than duplicate the record.

Time zone handling: store times in the instance time zone and convert at the boundary; an activity's time zone is derived from its resource or location, and mismatches cause off-by-hours scheduling errors.

Monitoring integration health means watching message queue backlog, failed message retries, and API error rates; a growing backlog indicates a consumer problem, not a producer problem.