Skip to main content

Oracle Field Service

Oracle Field Service is a cloud field service management platform that uses AI-driven scheduling and routing to optimize mobile workforces. It helps organizations schedule, dispatch, and manage technicians, connecting job assignments, inventory, real-time location tracking, and customer interactions. It integrates with ERP, supply chain, and CX systems for end-to-end visibility across service operations.

Oracle Field Service icon

Power end-to-end data operations for your Oracle Field Service API with Nexla. Our bi-directional Oracle Field Service connector is purpose-built for Oracle Field Service, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Oracle Field Service or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Oracle Field Service workflows fast, secure, and fully governed.

Features

Type: API

SourceDestination

  • Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
  • Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
  • API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
  • Request optimization with intelligent batching, retry, and caching to minimize API calls and costs

Prerequisites

To connect Nexla to Oracle Field Service, you need an active Oracle Field Service instance and administrator access to register an application and generate API credentials. Oracle Field Service uses HTTP Basic Authentication with a Client ID, instance name, and Client Secret — credentials that are created within the Oracle Field Service Configuration interface.

Oracle Field Service Instance URL

Your Oracle Field Service instance is accessible at a URL in one of the following formats:

  • https://{'{instance_name}'}.etadirect.com — for older instances
  • https://{'{instance_name}'}.fs.ocs.oraclecloud.com — for newer OCI-based instances

The exact base URL for your instance can be confirmed on the Configuration > About screen within the Oracle Field Service application, or by contacting your Oracle Field Service administrator. You will need this URL when configuring the Nexla credential.

Register an Application and Obtain API Credentials

Oracle Field Service requires that integrations authenticate using a registered application with a Client ID and Client Secret. To create these credentials, an Oracle Field Service administrator must complete the following steps:

  1. Log in to your Oracle Field Service instance with an administrator account.

  2. Navigate to Configuration in the main menu, and select Applications from the list of configuration options.

  3. In the left panel, click the + (plus) icon to open the New Application window.

  4. Enter a descriptive Application Name (for example, Nexla Integration) and a unique Application ID (for example, nexla_integration) to identify this application.

  5. Click Submit to create the application.

  6. In the application settings, locate the Authentication settings section and select the Authenticate using Client ID/Client Secret checkbox.

  7. The system will generate a Client Secret for the application. Copy and securely store this Client Secret immediately, as it may not be fully visible after you navigate away.

  8. Note the Application ID you specified when creating the application — this serves as the Client ID component of the credential.

The username format used for Oracle Field Service Basic Authentication follows the pattern client_id@instance_name, where client_id is the Application ID you created and instance_name is the name of your Oracle Field Service instance (the subdomain portion of your instance URL). For example, if your Application ID is nexla_integration and your instance URL is https://bestcustomer.etadirect.com, the username would be nexla_integration@bestcustomer.

For additional details about Oracle Field Service authentication, refer to the Oracle Field Service REST API Authentication documentation.

Authenticate

Credentials required

HTTP Basic Authentication for Oracle Field Service REST API.

FieldRequiredSecretDescription
Instance Base URLYesNoOracle Field Service base URL (e.g., https://yourinstance.etadirect.com)
Username or Client IDYesNoUsername or Client ID (format: client_id@instance_name)
Password or Client SecretYesYesPassword or Client Secret for authentication

Create a credential in Nexla

  1. After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.

  2. Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.

  3. Enter the base URL of your Oracle Field Service instance in the Instance Base URL field. This should be the root URL of your instance without any path components — for example, https://yourinstance.etadirect.com or https://yourinstance.fs.ocs.oraclecloud.com.

  4. Enter the username for API authentication in the Username or Client ID field. This must be formatted as client_id@instance_name, where client_id is the Application ID of the registered application and instance_name is the subdomain name of your Oracle Field Service instance. For example: nexla_integration@bestcustomer.

    The instance name is the subdomain of your Oracle Field Service URL. For the URL https://bestcustomer.etadirect.com, the instance name is bestcustomer. Combining with an Application ID of nexla_integration, the full username would be nexla_integration@bestcustomer.

  5. Enter the Client Secret associated with your registered application in the Password or Client Secret field. This is the secret that was generated when you created and configured the application in the Oracle Field Service Configuration > Applications interface.

    Important

    The Client Secret is sensitive and should be treated like a password. Store it securely and do not share it. If the Client Secret is lost or compromised, you will need to regenerate it in the Oracle Field Service Configuration > Applications interface.

  6. Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation.

Use as a data source

To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Oracle Field Service connector tile, then select the credential that will be used to connect to the Oracle Field Service instance, and click Next; or, create a new Oracle Field Service credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Oracle Field Service endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below.

List Activities

Retrieves a paginated list of activities from Oracle Field Service, with optional date range and filtering parameters. Use this endpoint when you need to pull bulk activity data for reporting, auditing, or downstream processing. Activities represent scheduled or completed field service tasks assigned to technicians.

  • This endpoint supports several optional filters. Configure as many or as few as are relevant to your use case — all fields are optional.
  • Enter a start date in the Date From field to limit activities to those on or after the specified date. Use the format YYYY-MM-DD (for example, 2024-01-01).

  • Enter an end date in the Date To field to limit activities to those on or before the specified date. Use the format YYYY-MM-DD (for example, 2024-01-31).

  • Enter a comma-separated list of resource IDs in the Resources field to filter activities assigned to specific technicians or resources. Resource IDs can be found using the List Resources endpoint.

  • Enter a comma-separated list of field names in the Fields field to limit the attributes returned for each activity. This can reduce payload size when only specific fields are needed. Refer to the Oracle Field Service Activities API documentation for available field names.

  • Enter true or false in the Include Children field to control whether child activities are included in the response. Child activities are sub-tasks or related activities nested under a parent activity.

  • Enter true or false in the Include Non-Scheduled field to control whether activities that have not yet been scheduled to a specific time slot are included in the results.

  • Enter a search query string in the Query field to further filter activities using Oracle Field Service's query syntax.

This endpoint uses offset-based pagination and will retrieve up to 5,000 records per run. For large datasets, consider using date range filters to narrow the results and improve performance.

Get Activity

Retrieves the full details of a single Oracle Field Service activity by its unique activity ID. Use this endpoint when you need to fetch complete information about a specific field service task, such as its status, assigned technician, scheduled time, customer details, and any associated notes or custom fields.

  • Enter the unique identifier of the activity in the Activity ID field. This is a required field. Activity IDs can be obtained from the List Activities or Search Activities endpoints. Refer to the Oracle Field Service Get Activity API documentation for details on the response structure.

Search Activities

Searches Oracle Field Service activities using custom field criteria and optional date range filters. Use this endpoint when you need to find activities that match a specific field value — for example, all activities for a particular customer name, phone number, or custom field — rather than retrieving all activities by date range.

  • Enter the name of the Oracle Field Service activity field to search within in the Search In Field field. This is a required field. For example, enter customerName to search by customer name, or enter a custom field label defined in your Oracle Field Service instance.

  • Enter the value to search for in the Search For Value field. This is a required field. The endpoint will return all activities where the specified field matches this value.

  • Optionally, enter a start date in the Date From field (format: YYYY-MM-DD) to limit search results to activities on or after this date.

  • Optionally, enter an end date in the Date To field (format: YYYY-MM-DD) to limit search results to activities on or before this date.

  • Optionally, enter a comma-separated list of field names in the Fields field to control which activity attributes are returned in the response.

  • Enter true or false in the Include Multiday field to control whether multi-day activities (activities that span more than one calendar day) are included in results.

  • Enter true or false in the Include Non-Scheduled field to control whether unscheduled activities are included in the search results.

This endpoint uses offset-based pagination and supports up to 5,000 records per run. For best performance, combine field-based search criteria with date range filters to limit result sets. Refer to the Oracle Field Service Search Activities API documentation for a full list of searchable fields.

List Resources

Retrieves a paginated list of resources from Oracle Field Service, with optional filters and field selection. Resources represent field technicians, vehicles, equipment, or any other entity that can be assigned activities. Use this endpoint to pull workforce data, build resource directories, or synchronize technician profiles with other systems.

  • Optionally, enter a comma-separated list of resource field names in the Fields field to limit which attributes are returned for each resource. Refer to the Oracle Field Service Resources API documentation for available field names.

  • Optionally, enter sub-entity names in the Expand field to embed related data within each resource record. Supported values include inventories, workZones, workSkills, and workSchedules. Multiple values can be provided as a comma-separated list.

  • Optionally, enter true or false in the Can Be Team Holder field to filter the list to only resources that are eligible to serve as team leaders or team holders.

  • Optionally, enter true or false in the Can Participate In Team field to filter the list to only resources that are eligible to participate as team members.

This endpoint supports pagination and can retrieve up to 5,000 resource records per run. Using the Expand parameter to embed sub-entities increases response payload size — use it selectively based on the data you actually need.

Get Resource

Retrieves the complete details of a single Oracle Field Service resource by its unique resource ID. Use this endpoint when you need detailed information about a specific technician, vehicle, or equipment item, including their work zones, skills, schedules, and inventory.

  • Enter the unique identifier of the resource in the Resource ID field. This is a required field. Resource IDs can be obtained from the List Resources endpoint. Refer to the Oracle Field Service Get Resource API documentation for the full response structure.

Get Resource Locations

Retrieves location history and tracking information for a specific Oracle Field Service resource. Use this endpoint to access GPS coordinates, timestamps, and location records associated with a technician or vehicle — useful for analyzing route efficiency, verifying on-site arrival times, or building location-based reports.

List Service Requests

Retrieves a paginated list of all service requests in the Oracle Field Service instance. Service requests represent customer-initiated requests for field service — they are typically created before activities are scheduled. Use this endpoint to pull service request data for tracking, reporting, or integration with CRM and ticketing systems.

  • This endpoint requires no additional configuration parameters — it returns all service requests accessible to the authenticated user. No additional configuration beyond selecting this endpoint is required.
  • The endpoint uses pagination to handle large datasets, automatically fetching additional pages as needed, up to 5,000 records per run. Refer to the Oracle Field Service Service Requests API documentation for details on response fields.

Get Service Request

Retrieves the complete details of a single Oracle Field Service service request by its unique request ID. Use this endpoint when you need full information about a specific customer service request, including its status, linked activities, and all associated field values.

List Booking Statuses

Retrieves all available booking statuses defined in the Oracle Field Service metadata. Booking statuses are configuration values used to categorize the state of appointments or reservations. Use this endpoint to populate lookup tables, validate status values used in other workflows, or synchronize status definitions with external systems.

  • This endpoint requires no additional configuration parameters and returns all booking statuses configured in your Oracle Field Service instance. No additional parameters need to be set.

Booking statuses are metadata configuration values and change infrequently. Consider scheduling this source to run less frequently than transactional endpoints such as List Activities or List Service Requests.

List Capacity Categories

Retrieves all available capacity categories defined in the Oracle Field Service metadata. Capacity categories define the types of work capacity tracked for scheduling purposes. Use this endpoint to understand capacity structures, validate category references used in other data flows, or synchronize capacity definitions with external planning or analytics tools.

  • This endpoint requires no additional configuration parameters and returns all capacity categories configured in your Oracle Field Service instance.

List Inventory Types

Retrieves all available inventory types defined in the Oracle Field Service metadata. Inventory types describe the categories of parts, tools, or materials that resources carry and consume during field service activities. Use this endpoint to pull inventory type definitions for catalog management, reporting, or integration with supply chain and inventory systems.

  • This endpoint requires no additional configuration parameters and returns all inventory types configured in your Oracle Field Service instance.

List Shifts

Retrieves all available shifts defined in the Oracle Field Service metadata. Shifts represent the work schedules and time blocks assigned to field resources. Use this endpoint to access shift definitions for workforce planning, scheduling analysis, or integration with HR and time-tracking systems.

  • This endpoint requires no additional configuration parameters and returns all shifts configured in your Oracle Field Service instance.

Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.

Manual configuration

Oracle Field Service data sources can also be manually configured to ingest data from any valid Oracle Field Service API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.

Oracle Field Service REST API endpoints follow the base path pattern https://{'{your_instance}'}.etadirect.com/rest/ofscCore/v1/ for core operational data, or https://{'{your_instance}'}.etadirect.com/rest/ofscMetadata/v1/ for metadata such as booking statuses, shifts, and inventory types. List endpoints return a JSON response with an items array — enter $.items[*] as the path to data to treat each item as a separate record.

Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Oracle Field Service data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.

Use as a destination

Click the + icon on the Nexset that will be sent to the Oracle Field Service destination, and select the Send to Destination option from the menu. Select the Oracle Field Service connector from the list of available destination connectors, then select the credential that will be used to connect to the Oracle Field Service organization, and click Next; or, create a new Oracle Field Service credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Oracle Field Service endpoints. Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

Create Activity

Creates a new activity in the Oracle Field Service system. Use this endpoint when you need to automatically generate field service tasks from external systems — for example, creating activities from CRM service requests, IoT alerts, or customer support tickets.

  • This endpoint uses an HTTP POST method and accepts a JSON body containing the activity fields to be created. The Nexset data will be sent as the request body in JSON format.
  • Ensure that the Nexset records include all required Oracle Field Service activity fields before sending to this destination. At minimum, Oracle Field Service activities typically require fields such as activity type, customer information, and a scheduled date. Refer to the Oracle Field Service Create Activity API documentation for a full list of accepted and required fields.

The activity will be created in an unscheduled state unless scheduling fields are provided. Oracle Field Service's AI-powered scheduling engine can be used to assign activities to resources after creation.

Update Activity

Updates an existing Oracle Field Service activity by its unique activity ID. Use this endpoint to modify activity details — such as updating status, customer information, scheduled time, or custom field values — based on changes in upstream systems.

  • Enter the unique identifier of the activity to update in the Activity ID field. This is a required field. The activity ID must correspond to an existing activity in Oracle Field Service. Activity IDs can be obtained from the List Activities or Search Activities source endpoints.

  • This endpoint uses an HTTP PATCH method, which means only the fields included in the Nexset record will be updated — fields not present in the payload will retain their existing values in Oracle Field Service. Refer to the Oracle Field Service Update Activity API documentation for a full list of updatable fields.

Complete Activity

Marks an existing Oracle Field Service activity as complete. Use this endpoint to programmatically close out field service tasks — for example, when a connected system (such as an ERP or billing platform) confirms that the work has been completed and invoiced.

  • Enter the unique identifier of the activity to complete in the Activity ID field. This is a required field. The activity must be in an active or in-progress state for the completion action to succeed. Refer to the Oracle Field Service Complete Activity API documentation for accepted body fields and completion requirements.

  • Optionally include completion details such as completion notes, time spent, or inventory consumed in the Nexset record body. These fields will be passed to Oracle Field Service as part of the completion request.
Important

Completing an activity is a state transition that cannot be easily reversed in Oracle Field Service. Ensure the correct activity ID is being passed before activating this destination flow.

Create Resource

Creates or fully replaces an Oracle Field Service resource by its unique resource ID. Use this endpoint to provision new field technicians, vehicles, or equipment in Oracle Field Service — for example, when onboarding new staff from an HR system or syncing resource records from an external workforce management platform.

  • Enter the unique identifier for the resource to create or replace in the Resource ID field. This is a required field. If a resource with this ID already exists, it will be fully replaced with the data in the Nexset record (HTTP PUT semantics). If no resource exists with this ID, a new resource will be created.

  • Ensure the Nexset record includes all required Oracle Field Service resource fields, such as resource type and name. Refer to the Oracle Field Service Create Resource API documentation for required and optional fields.

Because this endpoint uses HTTP PUT, omitting optional fields from the Nexset record will clear those fields on the resource in Oracle Field Service. Use the Update Resource endpoint (PATCH) if you only need to modify specific fields without affecting others.

Update Resource

Updates specific fields on an existing Oracle Field Service resource by its unique resource ID. Use this endpoint to make partial updates to technician or equipment records — for example, updating work schedules, skill assignments, contact information, or custom field values — without overwriting the entire resource record.

  • Enter the unique identifier of the resource to update in the Resource ID field. This is a required field. The resource must already exist in Oracle Field Service. Resource IDs can be obtained from the List Resources source endpoint.

  • This endpoint uses an HTTP PATCH method, meaning only the fields included in the Nexset record will be updated. Fields not present in the payload will retain their current values. Refer to the Oracle Field Service Update Resource API documentation for a full list of updatable fields.

Create Service Request

Creates a new service request in Oracle Field Service. Use this endpoint to automatically generate service requests from external systems such as CRMs, customer portals, IoT platforms, or call center tools — enabling seamless integration between customer-facing systems and field service dispatch.

  • This endpoint uses an HTTP POST method and accepts a JSON body containing the service request fields. The Nexset data will be sent as the request body.
  • Ensure the Nexset records include all required Oracle Field Service service request fields before sending to this destination. Refer to the Oracle Field Service Create Service Request API documentation for required and optional request fields.

Create User

Creates a new Oracle Field Service user with a specified login name. Use this endpoint to provision users programmatically — for example, when automating onboarding workflows from an HR system or an identity management platform.

  • Enter the login name for the new user in the Login field. This is a required field and must be unique within your Oracle Field Service instance. The login name is used by the user to sign in to Oracle Field Service.

  • This endpoint uses an HTTP PUT method and will create or replace the user record associated with the specified login. Ensure the Nexset record includes all required user fields such as name and role assignments. Refer to the Oracle Field Service Create User API documentation for required and optional fields.

Create or Update Inventory Type

Creates a new inventory type or fully replaces an existing inventory type by its label in Oracle Field Service metadata. Use this endpoint to manage the catalog of parts, materials, and equipment types used in field service operations — for example, syncing inventory type definitions from a parts management system or ERP.

  • Enter the label for the inventory type in the Label field. This is a required field and uniquely identifies the inventory type in Oracle Field Service. If an inventory type with this label already exists, it will be fully replaced. If it does not exist, a new inventory type will be created.

  • This endpoint uses an HTTP PUT method, meaning the entire inventory type record will be replaced with the data in the Nexset. Ensure all required fields are present. Refer to the Oracle Field Service Metadata API documentation for required and optional inventory type fields.

Manual configuration

Oracle Field Service destinations can also be manually configured to send data to any valid Oracle Field Service API endpoint. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.

Oracle Field Service REST APIs accept JSON format for all write operations. Use POST to create new records (activities, service requests), PUT to create or fully replace records (resources, users, inventory types), or PATCH to partially update existing records (activities, resources). Write endpoints follow the same base path pattern as read endpoints: https://{'{your_instance}'}.etadirect.com/rest/ofscCore/v1/ for core operations, or https://{'{your_instance}'}.etadirect.com/rest/ofscMetadata/v1/ for metadata operations.

Save & activate

Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To send the data to the configured Oracle Field Service endpoint, open the destination resource menu, and select Activate.

The Nexset data will not be sent to Oracle Field Service until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.