Reference · built on requestConnectorField service & CMMS

Oracle Field Service

Activities, routes, technician location, and inventories from Oracle Field Service through the ofscCore REST API and event subscriptions.

Request accessPricing ↗

About

Oracle Field Service schedules and routes mobile workers. Its Core REST API, at https://<instance_name>.fs.ocs.oraclecloud.com/rest/ofscCore/v1/, exposes activities with their inventories, links, required inventories, resource preferences, and submitted forms, plus capacity categories, multi-day segments, and a whereIsMyTech position lookup. Status changes run as custom actions on the activity: start, enroute, suspend, complete, notDone, cancel, delay, move, reopen. Instead of webhooks, an application creates an event subscription and polls Get Events with a page marker to receive activityCreated, activityMoved, activityCompleted, routeActivated, inventoryInstalled, and similar events.

Fibric polls that event stream, reads activities on demand, and proposes moves, delays, and status actions. A dispatcher approves each one before the custom action is called.

This is a reference listing. It documents what Fibric would read from Oracle Field Service and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Activities with status, time slot, resource, and custom properties through GET /rest/ofscCore/v1/activities and custom-actions/search
  • Technician position through GET /rest/ofscCore/v1/whereIsMyTech, and resource and route changes as resourceUpdated and routeActivated events
  • Activity inventories, required inventories, links, resource preferences, and submitted forms beneath each activity
  • Capacity categories per activity and multi-day segments of segmentable activities
  • Event streams from a subscription: activityCreated, activityMoved, activityStarted, activityCompleted, activityNotDone, inventoryInstalled, and formSubmitted
  • Each event's UTC time, the user who caused it, and its activityDetails, resourceDetails, or inventoryDetails block

Proposed actions

  • Target capability: propose creating an activity through POST /activities, or updating one through PATCH /activities/{activityId}
  • Target capability: propose moving an activity through custom-actions/move, or delaying it through custom-actions/delay
  • Target capability: propose a status action: start, enroute, suspend, complete, notDone, cancel, or reopen, each under custom-actions
  • Target capability: propose a bulk activity update through custom-actions/bulkUpdate, shown line by line before approval

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Re-route when an activity runs late

    activityDelayed and activityStarted events arrive with the resource. The operator reads the remaining route, proposes a move for the activity that no longer fits, and shows the dispatcher the new order.

    With Route Resequence

  • Tell the customer where the technician is

    activityTravelStarted fires. The operator reads whereIsMyTech, drafts the arrival notice, and proposes the send for approval.

    With ETA Notice

  • Catch work marked not done

    activityNotDone events are read with their activity details. The operator proposes a rebooking through POST /activities or a move, and records the reason for a person to approve.

    With Missed Stop

  • Confirm parts before dispatch

    Required inventories on tomorrow's activities are compared with the resource's inventory. Gaps produce a proposed delay or move, approved by the dispatcher before the route is set.

    With Parts Readiness

Requirements

  • An Oracle Field Service instance at https://<instance_name>.fs.ocs.oraclecloud.com and an administrator to register the application
  • API access granted to the application for the Core API, with the methods and ReadWrite objects it needs selected
  • A client ID and client secret shown under the application's Authentication settings
  • An event subscription created by the same application that will read the events, since only that application may read them
Authentication
An application registered under Configuration > Applications in Oracle Field Service, authenticating with HTTP Basic (clientId@instance and client secret) or an OAuth 2.0 token from /rest/oauthTokenService/v2/token via client credentials or a JWT assertion.

Limits

  • Events are pulled, not pushed: the integration must read faster than events are generated or older events are lost
  • At most 100 event subscriptions per environment; a subscription unused by Get Events for 36 hours expires
  • Get Events returns at most 1000 items per call, and custom property values above 5 KB are truncated in event payloads
  • OAuth access tokens expire in 3600 seconds; JWT assertions are meant to carry an exp of a minute or a few minutes

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Oracle Field Service ↗

Questions and answers

Does Oracle Field Service send webhooks?
No. Your application creates a subscription at POST /rest/ofscCore/v1/events/subscriptions, naming the events and fields it wants, then polls GET /rest/ofscCore/v1/events with subscriptionId and the nextPage marker from the previous call. Oracle advises polling every few seconds for busy subscriptions and every few minutes for quiet ones.
How does the connector authenticate?
Either HTTP Basic with clientId@instance and the client secret, or an OAuth 2.0 access token from /rest/oauthTokenService/v2/token using client_credentials or a JWT assertion. Tokens last 3600 seconds. The application, its API access, and any IP restrictions are set under Configuration > Applications.
Which activity actions can be proposed?
The custom actions documented on the activity: start, enroute, stopTravel, suspend, complete, notDone, cancel, delay, move, reopen, and startPrework, plus create through POST /activities, update through PATCH, and bulkUpdate. Each runs only after a person approves the proposal.
Ask about Oracle Field Service

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Oracle Field Service through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy