.png)
Salesforce Field Service Integration Guide
Salesforce Field Service integrates with enterprise systems through Salesforce REST, SOAP, Bulk, Composite, and event-based APIs.
Salesforce Field Service integration options at a glance
Salesforce Field Service is built on the Salesforce platform and exposes accessible Field Service objects through REST, SOAP, Composite, and Bulk APIs. Salesforce also supports selective event patterns through Change Data Capture, Platform Events, Pub/Sub API, and Outbound Messaging rather than a universal webhook for every change. Files use ContentVersion, ContentDocument, and ContentDocumentLink. OAuth 2.0 through a Connected App controls access. Martini can consume these APIs, receive configured event or callback traffic, expose REST APIs, and orchestrate workflows that query, transform, upsert, reconcile, and monitor Field Service data.
| Integration point | Supported by Salesforce Field Service? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Query, describe, create, update, delete, and upsert accessible WorkOrder, ServiceAppointment, Account, Asset, and other Salesforce objects using SOQL and standard resources. | Martini can consume Salesforce REST APIs from workflows, generate reusable API services where appropriate, map JSON payloads, and expose its own REST APIs for upstream systems. |
| GraphQL APIs | Limited | Salesforce GraphQL can provide API access for supported objects and fields, but Field Service coverage must be verified for the target org and API version. | Martini can consume GraphQL APIs, while the implementation should validate object coverage, query shape, permissions, and version compatibility before adoption. |
| SOAP APIs | Yes | Strongly typed queries, inserts, updates, deletes, and upserts for existing enterprise integrations or generated Salesforce clients. | Martini can consume Salesforce SOAP services and transform XML responses into canonical models or downstream requests. |
| Bulk and asynchronous APIs | Yes | High-volume migration, historical synchronization, and large-scale loading or export of WorkOrder, ServiceAppointment, Asset, Product2, and related data. | Martini can submit jobs, poll status, retrieve success and failure results, reconcile counts, and retry eligible records separately. |
| Composite APIs | Yes | Combine related REST operations, such as creating a WorkOrder with related records, while reducing request overhead for smaller multi-operation transactions. | Martini can construct Composite requests, pass references between operations, interpret per-operation results, and apply workflow-level error handling. |
| Webhooks / outbound callbacks | Limited | Outbound Messaging and configured event mechanisms can notify external systems for selected workflow or approval conditions; Salesforce does not provide a universal webhook for every Field Service change. | Martini can receive supported callback traffic through an exposed API or webhook workflow and then retrieve the current Salesforce resource before processing it. |
| Events | Limited | Change Data Capture, Platform Events, and Pub/Sub API support selected change or business-event scenarios subject to object coverage, configuration, permissions, retention, and replay behavior. | Martini can orchestrate event-driven workflows through a configured event or API gateway, deduplicate deliveries, and persist replay or correlation state. |
| File / attachment APIs | Yes | Upload, download, and associate Salesforce Files using ContentVersion, ContentDocument, and ContentDocumentLink; legacy Attachment records may also exist. | Martini can transfer file metadata and binary content, create records in the required order, associate files with Salesforce objects, and apply size and permission checks. |
| Authentication | Yes | OAuth 2.0 through Connected Apps supports authorization code, JWT Bearer, refresh-token, and supported client-credentials patterns, controlled by Salesforce permissions and sharing. | Martini can use secured environment configuration for OAuth credentials, tokens, private keys, and endpoint settings rather than embedding secrets in workflows. |
How Salesforce Field Service exposes data and business events
Salesforce Field Service REST APIs
Salesforce REST APIs support queries, SOQL and SOSL searches, describe operations, and CRUD or upsert operations for accessible Salesforce and Field Service objects. REST is generally the primary choice for new API-led integrations.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to Salesforce, retrieves pages of data or accepts an API request, maps Salesforce JSON into a canonical model, applies business rules, and writes to the target system or Salesforce.
Implementation sequence
Salesforce Bulk and Composite APIs
Bulk API 2.0 provides asynchronous high-volume ingestion and retrieval, while Composite APIs combine smaller related REST operations. Both remain subject to Salesforce validation, sharing, and API limits.
Martini implementation pattern
Martini implementation pattern: a workflow selects Bulk or Composite processing based on volume, submits the request, monitors asynchronous status or per-operation results, and reconciles successful and failed records independently.
Implementation sequence
Salesforce Change Data Capture and Platform Events
Salesforce supports Change Data Capture for configured supported objects and Platform Events for application-defined business events. Pub/Sub API provides access to supported event channels, but coverage is not universal across Field Service objects or fields.
Martini implementation pattern
Martini implementation pattern: Martini receives configured event traffic through an API or event gateway, records event and replay identifiers, retrieves the current Salesforce object when necessary, and invokes downstream processing with duplicate detection.
Implementation sequence
Salesforce Outbound Messaging
Outbound Messaging can send SOAP-based notifications when configured Salesforce workflow or approval conditions are met. It is selective and should not be represented as a generic webhook for all Field Service changes.
Martini implementation pattern
Martini implementation pattern: Martini exposes an endpoint for the configured outbound message, validates the notification, correlates it to Salesforce data, and retrieves the authoritative record before executing downstream logic.
Implementation sequence
Salesforce SOAP APIs
Salesforce SOAP API provides strongly typed enterprise operations for queries, inserts, updates, deletes, and upserts. It remains relevant for existing enterprise applications even when REST is preferred for new designs.
Martini implementation pattern
Martini implementation pattern: Martini consumes the SOAP contract, transforms XML into internal models, applies workflow rules, and converts the result into the target system's required format while preserving Salesforce fault details.
Implementation sequence
Common Salesforce Field Service integration patterns
Pattern 1: Synchronize work orders and appointments
When to use this pattern
Use this pattern when an ERP, customer portal, or operational platform needs current Salesforce Field Service work and appointment information. A schedule or configured event mechanism can identify new and changed records while overlap windows and deduplication protect against missed or repeated changes.
Integration direction
Example Mapping
| Salesforce Field Service Field | Canonical Field | Target Field |
|---|---|---|
| WorkOrder.WorkOrderNumber | serviceWorkNumber | NetSuite service order reference |
| ServiceAppointment.EarliestStartTime | appointmentStart | NetSuite scheduled start |
| Account.Id | customerSourceId | NetSuite customer external ID |
| WorkOrder.Status | serviceStatus | NetSuite fulfillment or billing status |
Martini implementation pattern
A Martini scheduler or event-triggered workflow queries Salesforce with selective SOQL, follows pagination, resolves related Account, Contact, Asset, and ServiceAppointment data, maps it to NetSuite, and performs an idempotent create or update. Failed records are isolated with Salesforce errors, correlation IDs, and retry eligibility.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Create Field Service work from an ERP
When to use this pattern
Use this pattern when an ERP or order-management application determines that a customer service visit is required. The workflow validates customer, asset, product, territory, skill, priority, and appointment-window information before creating related Salesforce records.
Integration direction
Example Mapping
| Salesforce Field Service Field | Canonical Field | Target Field |
|---|---|---|
| ERP service request identifier | sourceRequestId | WorkOrder external ID |
| ERP customer identifier | customerId | Account external ID |
| ERP requested service | serviceLine | WorkOrderLineItem description or Product2 |
| ERP requested appointment window | requestedWindow | ServiceAppointment time fields |
Martini implementation pattern
Martini exposes an API or consumes the ERP API, validates the request, resolves Salesforce relationships, and uses Composite or REST operations in dependency order. External IDs and upserts make retries safe, while validation and permission failures are routed for correction rather than blindly retried.
Martini capabilities used
- APIs
- workflows
- data mapping
- validation
- business rules
- idempotency
- error handling
Pattern 3: Propagate technician and appointment status
When to use this pattern
Use this pattern when customers, billing teams, or service-management users need status updates such as scheduled, dispatched, in progress, completed, canceled, or unable to complete. The exact status vocabulary must follow the target Salesforce org configuration.
Integration direction
Example Mapping
| Salesforce Field Service Field | Canonical Field | Target Field |
|---|---|---|
| ServiceAppointment.Status | appointmentStatus | ServiceNow request state |
| AssignedResource.ServiceResourceId | assignedTechnicianId | ServiceNow assignee reference |
| WorkOrder.CompletedDate | completionTime | ServiceNow completion timestamp |
| WorkOrder.Id | fieldServiceWorkId | ServiceNow correlation ID |
Martini implementation pattern
Martini receives supported CDC, Platform Event, or outbound notification traffic, or detects changes on a schedule. It retrieves the authoritative Salesforce object, maps status and completion data, applies transition rules, and updates ServiceNow with duplicate detection and retry handling.
Martini capabilities used
- event-driven workflows
- API consumption
- data mapping
- state management
- business rules
- monitoring
Pattern 4: Migrate or export historical Field Service data
When to use this pattern
Use this pattern for initial migration, historical reporting, or large periodic transfers of WorkOrder, ServiceAppointment, WorkOrderLineItem, Asset, and related data. Bulk API 2.0 is more appropriate than repeatedly issuing small REST queries at high volume.
Integration direction
Example Mapping
| Salesforce Field Service Field | Canonical Field | Target Field |
|---|---|---|
| WorkOrder.Id | sourceWorkOrderId | work_order.salesforce_id |
| ServiceAppointment.SchedStartTime | scheduledStart | service_appointment.scheduled_start |
| WorkOrderLineItem.Quantity | quantity | work_order_line_item.quantity |
| Asset.SerialNumber | assetSerialNumber | asset.serial_number |
Martini implementation pattern
A Martini workflow submits a Bulk API job, polls its status, retrieves successful and failed results, transforms the data into database-ready records, and reconciles counts. It records the Salesforce job ID, retries only eligible failures, and preserves rejected rows for review.
Martini capabilities used
- workflows
- Bulk API consumption
- data transformation
- database integration
- reconciliation
- error handling
Applications commonly integrated with Salesforce Field Service
Salesforce Field Service can be integrated with adjacent business applications when service execution, customer context, financial processing, workforce data, or mapping needs to cross system boundaries. These are implementation patterns rather than claims of dedicated native integrations between Salesforce and each application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| NetSuite | Synchronize customers, products, sales orders, invoices, completed work, and billable service activity. | NetSuite → Martini → Salesforce Field Service | Martini exposes or consumes the relevant APIs, maps order and customer data to WorkOrder and WorkOrderLineItem objects, and returns completion or billing status with idempotent upserts and error handling. |
| SAP S/4HANA | Exchange service orders, installed-base information, materials, billing data, and service completion results. | SAP S/4HANA → Martini → Salesforce Field Service | A Martini workflow retrieves or receives SAP service data, resolves Accounts, Assets, Products, and ServiceTerritories, then creates or updates Salesforce work while reconciling partial failures. |
| Oracle Fusion Cloud ERP | Coordinate service execution with orders, inventory, procurement, and financial processing. | Oracle Fusion Cloud ERP → Martini → Salesforce Field Service | Martini validates inbound ERP requests, creates related WorkOrder and WorkOrderLineItem records, and sends completion and billable activity back after applying business rules. |
| ServiceNow | Synchronize incidents, service requests, field work, and operational status when service-management processes span both platforms. | ServiceNow → Martini → Salesforce Field Service | Martini correlates ServiceNow incidents or requests with Salesforce WorkOrder and ServiceAppointment records, routes status changes in both directions, and retains correlation identifiers for retry and reconciliation. |
| Salesforce Service Cloud | Connect customer cases and service requests to Field Service WorkOrder and ServiceAppointment processes. | Salesforce Service Cloud → Martini → Salesforce Field Service | A Martini workflow maps Case, Account, Contact, and Asset context into Field Service objects and returns appointment and completion outcomes to the customer-service process. |
| Salesforce Sales Cloud | Use accounts, contacts, opportunities, assets, and commercial context to initiate service work. | Salesforce Sales Cloud → Martini → Salesforce Field Service | Martini consumes Salesforce APIs or events, applies service-eligibility and territory rules, and creates or updates Field Service work using stable Salesforce identifiers. |
| Workday | Exchange worker, organizational, or cost-center data where technician and workforce administration is managed in Workday. | Workday → Martini → Salesforce Field Service | A scheduled Martini workflow retrieves permitted workforce data, maps it to ServiceResource or related operational attributes, and records rejected or unmatched resources for review. |
| Google Maps Platform | Support address validation, geocoding, travel estimation, and map-based service planning where the Field Service configuration requires it. | Salesforce Field Service → Martini → Google Maps Platform | Martini retrieves address or appointment context, calls the relevant Google Maps Platform API, validates the response, and returns normalized location or travel data to the scheduling workflow. |
How to build a Salesforce Field Service integration in Martini
Objective
Establish Salesforce access with a Connected App and an OAuth 2.0 flow appropriate for the deployment model.
Instructions in Martini
- Configure the Salesforce base URL, client details, scopes, and token settings
- Store client secrets, refresh tokens, and private keys in secured environment configuration
- Use least-privilege Salesforce profiles, permission sets, sharing, and field-level access
Objective
Select a scheduled, API-led, event-driven, or callback trigger based on the required latency and Salesforce coverage.
Instructions in Martini
- Use a scheduler for controlled incremental synchronization
- Use CDC, Platform Events, Pub/Sub API, or Outbound Messaging only for supported configured scenarios
- Use a Martini API when an ERP or other application must submit service requests
Objective
Retrieve the authoritative Salesforce objects and related records needed for the business transaction.
Instructions in Martini
- Use REST and SOQL for ordinary volumes and targeted queries
- Follow REST pagination or query continuation links
- Use Bulk API 2.0 for high-volume transfers
- Retrieve the current object after an event when the notification does not contain sufficient fields
Objective
Coordinate dependency order, relationship resolution, asynchronous jobs, and downstream calls in a maintainable Martini workflow.
Instructions in Martini
- Resolve Accounts, Contacts, Assets, Products, territories, resources, and parent WorkOrders before dependent writes
- Choose Composite operations for related smaller transactions
- Poll Bulk jobs and persist job identifiers and processing state
Objective
Convert Salesforce objects and status models into the canonical and target-system structures.
Instructions in Martini
- Map WorkOrder, ServiceAppointment, WorkOrderLineItem, and related objects explicitly
- Normalize timestamps, operating hours, and time zones
- Transform JSON or XML payloads and preserve Salesforce identifiers for correlation
Objective
Validate relationships, status transitions, territory and skill requirements, permissions, and source-system identifiers before writing data.
Instructions in Martini
- Use stable external IDs and upsert behavior where appropriate
- Reject incomplete or invalid records with actionable error details
- Avoid hard-coding status transitions without checking the target org configuration
Common Salesforce Field Service data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| WorkOrder | Represents work to be performed for a customer, asset, location, or service process. | ERP, customer service platforms, billing applications, operational systems | Martini queries, creates, updates, or upserts WorkOrder records, resolves related Accounts, Contacts, Assets, and ServiceTerritories, and applies status and validation rules. |
| ServiceAppointment | Represents a scheduled customer visit or appointment associated with a WorkOrder. | Scheduling platforms, customer portals, service management platforms, billing systems | Martini maps appointment windows, time zones, statuses, and assignments, then uses event or scheduled workflows to propagate changes with duplicate protection. |
| WorkOrderLineItem | Represents an individual service, task, product, or work component associated with a WorkOrder. | ERP, inventory systems, procurement systems, billing platforms | Martini creates line items after resolving the parent WorkOrder and related Product2 or Asset references, while retaining per-record failures for reconciliation. |
| ServiceResource | Represents a technician, crew, vehicle, facility, or other resource that can perform field work. | Workforce systems, scheduling platforms, HR applications, operational databases | Martini synchronizes permitted workforce attributes, resolves resource identifiers, and avoids assuming that every external worker is eligible for scheduling. |
| ServiceTerritory | Defines the geographic or operational area in which service is delivered. | ERP, workforce platforms, mapping services, scheduling applications | Martini maps territory codes and operating relationships, validates references before work creation, and handles configuration-specific territory rules. |
| OperatingHours | Defines when a service territory, resource, or other Field Service entity is available. | Scheduling systems, workforce platforms, customer portals | Martini normalizes time zones and availability windows and preserves the Salesforce configuration needed for appointment and scheduling decisions. |
Authentication and security considerations
OAuth 2.0 and Connected Apps
Salesforce access is commonly controlled through a Connected App and an OAuth 2.0 flow such as JWT Bearer, authorization code, refresh-token, or a supported client-credentials configuration. Martini should use the flow supported by the target Salesforce org and integration model.
Least-privilege access
Salesforce profiles, permission sets, object permissions, field-level security, sharing rules, and record-level access determine which Field Service data an integration user can access.
Secret protection
Client secrets, private keys, refresh tokens, and other credentials should be stored in Martini secured environment configuration rather than embedded in workflows or source-controlled mappings.
Operational considerations for Salesforce Field Service integrations
Limits and pagination
Salesforce enforces org-level API limits and may impose limits on Bulk, Composite, event delivery, concurrency, and long-running operations. Use controlled concurrency, backoff, and retry policies. Follow REST continuation links and use Bulk API for large exports.
Idempotency and partial failures
Use external IDs and upserts to prevent duplicate WorkOrder or ServiceAppointment records. Composite and Bulk responses can contain mixed success and failure results, so retain per-record errors and retry only eligible failures.
Events and schema changes
CDC and Platform Events require configured channels, replay handling, and retention awareness. Salesforce administrators may change fields, picklists, validation rules, permissions, or status transitions, so mappings should be versioned and tested in representative sandboxes.
Time zones and files
Normalize appointment windows while preserving org, user, and territory time zones. File integrations should account for ContentVersion creation order, binary size, permissions, retention, and any required scanning or downstream controls.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate beyond a single API call
Salesforce Field Service integrations often require relationship resolution, dependency ordering, status rules, asynchronous Bulk jobs, and calls to multiple enterprise systems. Martini coordinates these operations in workflows rather than leaving sequencing and recovery to scattered scripts.
Centralize mapping and business rules
Martini provides reusable API and workflow assets for transforming WorkOrder, ServiceAppointment, resource, territory, file, and event data into canonical and target-specific models.
Improve reliability and maintainability
Controlled retries, idempotent upserts, event replay state, error routing, logging, and environment-based security configuration provide a more maintainable operating model than point-to-point code.
Expose controlled interfaces
Martini can expose a REST API façade for upstream applications while preserving Salesforce-specific authentication, object relationships, validation, and orchestration logic behind a governed integration boundary.
Frequently asked questions
Salesforce Field Service can be integrated through Salesforce REST, Composite, Bulk, SOAP, and selectively supported event mechanisms such as Change Data Capture, Platform Events, Pub/Sub API, and Outbound Messaging. Salesforce Files use ContentVersion, ContentDocument, and ContentDocumentLink, while OAuth 2.0 through Connected Apps controls access.
Yes. Martini can integrate with Salesforce Field Service by consuming its REST, SOAP, Bulk, Composite, and supported event-related APIs, receiving configured callback traffic, exposing APIs for upstream systems, and orchestrating mappings, validation, synchronization, and reconciliation.
No dedicated Salesforce Field Service connector is required. Martini can use Salesforce's confirmed native APIs, event mechanisms, outbound messaging, file APIs, and OAuth 2.0 authentication through standards-based workflows and APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Salesforce Field Service. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Salesforce, infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
REST is generally the primary choice for new API-led integrations. Use Composite for smaller related operations, Bulk API 2.0 for high-volume asynchronous transfers, and SOAP where an existing enterprise client depends on its strongly typed contract. GraphQL is available on a limited basis and requires verification of Field Service object and field coverage.
Potentially. Configured Change Data Capture, Platform Events, Pub/Sub API channels, or Outbound Messaging can provide event or callback traffic for selected scenarios. Coverage depends on object support, org configuration, permissions, retention, and replay behavior, so Salesforce should not be treated as exposing a universal webhook for every Field Service change.
Martini can use timestamps such as SystemModstamp, external IDs and upserts, scheduled REST queries, Bulk API jobs, or supported event streams. Robust workflows use overlap windows, pagination, replay handling, deduplication, relationship ordering, and reconciliation to account for retries, late changes, and partial failures.
Yes. Martini can expose REST APIs that provide a controlled canonical interface for ERPs, portals, or other applications. The façade can validate requests, apply business rules, invoke Salesforce APIs, transform responses, and hide Salesforce-specific relationship and authentication details from consumers.
Related Martini documentation
Salesforce APIs
Workflows
Operations
Integrate Salesforce Field Service with Martini
Use Martini to connect Salesforce Field Service with enterprise applications through secure APIs, event-driven workflows, data mapping, and reliable synchronization.