.png)
ServiceMax Integration Guide
Integrate ServiceMax field-service data with enterprise applications through REST APIs, Salesforce-based APIs, selected event mechanisms, scheduled workflows, and controlled file transfers.
ServiceMax integration options at a glance
ServiceMax integrations primarily use REST APIs, including Salesforce REST APIs in Salesforce-based deployments, to retrieve and update Work Orders, Service Requests, Accounts, Contacts, and Installed Products. Selected deployments may provide Salesforce Platform Events, Change Data Capture, outbound messages, or other callback mechanisms, but event coverage must be verified by object and tenant. Salesforce Bulk or asynchronous APIs can support historical and high-volume synchronization. File and attachment transfers may use Salesforce Files, legacy attachments, or ServiceMax-specific endpoints. Martini can authenticate with OAuth 2.0, orchestrate scheduled or event-driven workflows, transform data, apply tenant-specific business rules, and expose normalized APIs to downstream systems.
| Integration point | Supported by ServiceMax? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve and update Work Orders, Service Requests, Accounts, Contacts, Installed Products, service status, and technician assignments. Salesforce REST APIs may provide access in Salesforce-based ServiceMax deployments. | Martini can consume REST endpoints from workflows, manage OAuth-based configuration, transform responses, apply business rules, and expose normalized APIs. |
| GraphQL APIs | Not confirmed | No official current ServiceMax GraphQL API was confirmed in the supplied research. | Martini can consume GraphQL APIs when a deployment documents them, but GraphQL should not be assumed for ServiceMax. |
| SOAP APIs | Limited | Historical or product-specific web-service capabilities may exist, but a current generally recommended SOAP surface was not confirmed. | Martini can consume documented SOAP services where the target tenant enables them, with tenant-level authentication and error handling. |
| Webhooks / outbound callbacks | Limited | Salesforce Platform Events, Change Data Capture, outbound messages, or selected ServiceMax callbacks may support event-driven status and object notifications. | Martini can receive documented callbacks through webhook workflows, retrieve the current resource when notifications contain only identifiers, and reconcile gaps with polling. |
| Bulk / async / batch APIs | Limited | Salesforce Bulk or asynchronous APIs may support historical Work Order migration, large Account and Contact loads, Installed Product synchronization, and backfills. | Martini can orchestrate bounded batches, checkpoints, transformations, and restartable workflows after confirming object access and licensing. |
| File / attachment APIs | Limited | Service documents, field photos, inspection records, and attachments may be exposed through Salesforce Files, legacy attachments, ServiceMax storage, or separate endpoints. | Martini can separate metadata from binary transfer, apply file rules, transfer content to target repositories, and prevent duplicate uploads with source identifiers or checksums. |
| Authentication | Yes | Salesforce-based API access commonly uses OAuth 2.0, scopes, connected-application permissions, bearer tokens, and Salesforce user or object permissions. | Martini can store credentials and refresh tokens in secrets or environment configuration and use separate credentials for development, test, and production. |
| Database access | Not confirmed | Direct SQL access to the ServiceMax production data store should not be assumed; supported APIs, exports, reporting, or approved data-platform interfaces are preferred. | Martini can consume supported APIs and files or connect to an explicitly provisioned database, but it should not bypass documented ServiceMax interfaces. |
How ServiceMax exposes data and business events
ServiceMax REST APIs
REST is the primary mechanism to investigate for new ServiceMax integrations. Depending on the deployment, REST resources may be ServiceMax-specific or Salesforce resources used to access authorized ServiceMax data. Exact objects, relationships, fields, and permissions vary by product edition and tenant.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with the configured OAuth 2.0 mechanism, calls the appropriate REST resource, handles pagination and related-object retrieval, maps the response into a canonical model, applies tenant-specific rules, and writes to the target system. It can also expose an API façade that hides deployment-specific ServiceMax details from downstream applications.
Implementation sequence
ServiceMax Event Notifications and Callbacks
Some ServiceMax and Salesforce-based deployments may support Platform Events, Change Data Capture, outbound messages, or other callback mechanisms. Coverage depends on the object, event, product edition, tenant configuration, and whether the notification contains a full object or only an identifier.
Martini implementation pattern
Martini implementation pattern: expose a controlled webhook endpoint or receive the documented callback, validate the request, inspect the event type, retrieve the current ServiceMax resource when needed, and process the event through an idempotent workflow. Scheduled reconciliation should complement event processing when delivery or coverage is incomplete.
Implementation sequence
Salesforce Bulk and Asynchronous APIs
Salesforce-based ServiceMax environments may use bulk or asynchronous APIs for large Work Order, Installed Product, Account, and Contact loads, historical migrations, nightly reconciliation, and outage backfills. Availability depends on object access, licensing, and deployment configuration.
Martini implementation pattern
Martini implementation pattern: a workflow submits bounded batches, tracks the asynchronous job or batch state, retrieves results, transforms successful rows, and routes rejected rows to an exception process. Standard REST remains more appropriate for smaller operational transactions.
Implementation sequence
ServiceMax File and Attachment APIs
Service documents, mobile photos, inspection records, and attachments may be stored in Salesforce Files, legacy attachments, ServiceMax storage, or another related system. The file endpoint, authorization, size limits, and availability timing must be verified for the target deployment.
Martini implementation pattern
Martini implementation pattern: process Work Order metadata separately from binary content, retrieve file metadata and authorized downloads, apply MIME and size policies, transfer the file to the target repository, and record source identifiers or checksums to prevent duplicates.
Implementation sequence
Scheduled Incremental Synchronization
When event coverage is unavailable or incomplete, scheduled REST synchronization can use a documented last-modified field, system-modified field, or change token. A small overlap window and periodic reconciliation reduce the risk of missed updates.
Martini implementation pattern
Martini implementation pattern: a scheduler starts the workflow, loads the last successful watermark, queries a bounded time range, processes pages, and advances the checkpoint only after target writes succeed. The workflow can separate operational traffic from historical or bulk processing.
Implementation sequence
Common ServiceMax integration patterns
Pattern 1: Synchronize Work Orders to an ERP
When to use this pattern
Use this pattern when completed or operational Work Orders must produce service, parts, labor, inventory, or financial transactions in an ERP such as SAP S/4HANA, Oracle ERP Cloud, or NetSuite. It is suitable for scheduled incremental processing when event coverage is not universal.
Integration direction
Example Mapping
| ServiceMax Field | Canonical Field | Target Field |
|---|---|---|
| Work Order identifier | serviceWorkOrderId | serviceOrderNumber |
| Status | serviceStatus | orderStatus |
| Account | customerId | customerAccount |
| Parts and labor | serviceLineItems | materialAndLaborLines |
Martini implementation pattern
A scheduled Martini workflow queries Work Orders by modification watermark and status, retrieves required Account, Installed Product, technician, parts, and completion data, then maps the result to the ERP model. Business rules validate allowed completion states and required financial fields. Stable source identifiers support idempotent upserts, while throttling, transient failures, rejected transactions, and watermark advancement are handled separately.
Martini capabilities used
- scheduled workflows
- REST API consumption
- data mapping
- business rules
- idempotent upserts
- error handling and retry
- checkpoint management
Pattern 2: Synchronize customers and Installed Products with Salesforce
When to use this pattern
Use this pattern when CRM and field-service teams need consistent Accounts, Contacts, Installed Products, and service context. Bidirectional synchronization requires explicit ownership rules for customer identity, addresses, asset identifiers, and lifecycle status.
Integration direction
Example Mapping
| ServiceMax Field | Canonical Field | Target Field |
|---|---|---|
| Account identifier | customerExternalId | Account.External_Id__c |
| Installed Product identifier | assetExternalId | Asset.External_Id__c |
| Contact email | contactEmail | Contact.Email |
| Installed Product status | assetLifecycleStatus | Asset.Status |
Martini implementation pattern
Martini workflows consume the relevant ServiceMax or Salesforce REST resources, normalize identifiers and relationships, and apply field-level ownership rules before writing changes in either direction. Validation expressions reject incomplete customer or asset relationships, and correlation keys prevent duplicate Accounts, Contacts, and Installed Products after retries.
Martini capabilities used
- REST API consumption
- bidirectional workflows
- data mapping
- validation
- business rules
- duplicate prevention
- workflow logging
Pattern 3: Route service events to ServiceNow
When to use this pattern
Use this pattern when a ServiceMax Work Order or Service Request status should create or update an operational record in ServiceNow. Because event coverage is deployment-dependent, combine supported callbacks with scheduled reconciliation where required.
Integration direction
Example Mapping
| ServiceMax Field | Canonical Field | Target Field |
|---|---|---|
| Service Request identifier | requestExternalId | correlation_id |
| Work Order priority | servicePriority | priority |
| Work Order status | serviceStatus | state |
| Service location | serviceLocation | location |
Martini implementation pattern
Martini receives a documented callback or identifies the change through polling, retrieves the current resource when necessary, and applies routing rules based on status, priority, and service location. It creates or updates ServiceNow records using the ServiceMax identifier as a correlation key, distinguishes validation failures from transient errors, and runs reconciliation for missed events.
Martini capabilities used
- webhook workflows
- scheduled reconciliation
- REST API consumption
- conditional routing
- data mapping
- idempotency
- retry and exception handling
Pattern 4: Transfer Work Order documents to an analytics or repository platform
When to use this pattern
Use this pattern when field photos, inspection documents, or completion files must be retained in a document repository, data lake, or analytics platform. It is appropriate where metadata and binary content require separate processing and controls.
Integration direction
Example Mapping
| ServiceMax Field | Canonical Field | Target Field |
|---|---|---|
| Work Order identifier | workOrderId | WORK_ORDER_ID |
| File name | documentName | FILE_NAME |
| MIME type | contentType | CONTENT_TYPE |
| Inspection result | inspectionOutcome | INSPECTION_OUTCOME |
Martini implementation pattern
A Martini workflow retrieves Work Order metadata and related file metadata, downloads authorized binary content through the verified endpoint, applies file-size, MIME, malware, and checksum rules, and writes metadata and content to the target platform. Failed downloads and partial uploads are isolated from successful items so the workflow can retry safely.
Martini capabilities used
- REST API consumption
- file handling
- data transformation
- business rules
- duplicate detection
- bounded batch processing
- error handling
Applications commonly integrated with ServiceMax
ServiceMax commonly participates in enterprise field-service architectures alongside CRM, ERP, ITSM, engineering, and analytics platforms. Exact objects, mappings, and integration direction depend on the ServiceMax product edition, Salesforce configuration, and target application APIs.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer context, Accounts, Contacts, Installed Products, service history, and field-service execution data between CRM and ServiceMax. | ServiceMax → Martini → Salesforce | Use REST API workflows with OAuth 2.0, stable Salesforce or ServiceMax identifiers, explicit field ownership rules, and idempotent upserts for bidirectional synchronization. |
| SAP S/4HANA | Exchange service orders, materials, inventory, billing, and financial completion data between field operations and the ERP. | ServiceMax → Martini → SAP S/4HANA | Retrieve changed Work Orders and related Installed Products, map labor and parts into SAP transaction structures, validate status and required fields, then retry transient failures while routing business rejections to exceptions. |
| Oracle ERP Cloud | Transfer service charges, parts, customer information, and financial transactions for downstream accounting and fulfillment. | ServiceMax → Martini → Oracle ERP Cloud | Use scheduled incremental extraction or verified event notifications, transform ServiceMax identifiers and amounts into Oracle payloads, and persist source-to-target correlation keys. |
| ServiceNow | Coordinate incidents, customer requests, operational tasks, and field-service work across ITSM and field-service teams. | ServiceMax → Martini → ServiceNow | Receive a supported callback or poll ServiceMax for changed Service Requests and Work Orders, map statuses and priorities, create or update ServiceNow records, and reconcile event gaps. |
| Microsoft Dynamics 365 | Synchronize customers, assets, opportunities, cases, and service execution data across CRM and field operations. | ServiceMax → Martini → Microsoft Dynamics 365 | Build bidirectional workflows with explicit ownership for customer, asset, and lifecycle fields, using validation expressions and deterministic upsert keys. |
| NetSuite | Send completed service, parts, and billing information to the ERP and return customer or item data to field operations. | ServiceMax → Martini → NetSuite | Transform completed Work Orders and parts data into NetSuite API structures, apply configurable completion rules, and use checkpoints and retries for scheduled reconciliation. |
| Jira | Create engineering or product issues from recurring field failures and return issue references or status to service teams. | ServiceMax → Martini → Jira | Route qualifying Work Orders or Service Requests through business rules, create Jira issues with mapped asset and failure context, and write the Jira key back after successful creation. |
| Snowflake | Centralize Work Orders, Installed Products, service history, and technician-performance data for analytics. | ServiceMax → Martini → Snowflake | Extract incrementally through REST APIs, exports, or an approved intermediate pipeline, normalize relationships, load bounded batches, and retain watermarks for restartable processing. |
How to build a ServiceMax integration in Martini
Objective
Confirm the ServiceMax product edition, tenant API surface, Salesforce relationship where applicable, OAuth configuration, scopes, permissions, token refresh behavior, and target-system credentials.
Instructions in Martini
- Identify the documented ServiceMax or Salesforce API resources required by the workflow.
- Store client IDs, secrets, refresh tokens, and other credentials in Martini secrets or environment configuration.
- Use separate credentials and permissions for development, test, and production.
- Verify that the configured user can access the required ServiceMax-specific operations and related objects.
Objective
Select an event, callback, scheduler, or API trigger based on the required object coverage and the confirmed capabilities of the deployment.
Instructions in Martini
- Use a documented callback or event mechanism only for supported objects and events.
- Use a scheduler with a modified-date or change-token filter when event coverage is incomplete.
- Expose a Martini API when another application must initiate service synchronization.
Objective
Retrieve current ServiceMax data and related objects while respecting pagination, quotas, relationship behavior, and API-version constraints.
Instructions in Martini
- Persist continuation tokens, cursors, or page state where applicable.
- Use queries or supported expansions to avoid excessive nested requests.
- Retrieve the current resource after an event when the notification contains only an identifier.
- Use stable source identifiers and an overlap window for incremental synchronization.
Objective
Coordinate retrieval, enrichment, transformation, target writes, checkpoints, and exception paths as a maintainable Martini workflow.
Instructions in Martini
- Separate operational synchronization from historical or bulk processing.
- Resolve Accounts, Contacts, Installed Products, technicians, locations, and parts only when required.
- Use conditional routing for status, priority, ownership, and target-system decisions.
- Persist correlation identifiers and successful watermarks outside an individual execution.
Objective
Convert ServiceMax and Salesforce-based responses into canonical and target-specific models without relying on undocumented field ordering or tenant assumptions.
Instructions in Martini
- Map Work Orders, Service Requests, Installed Products, Accounts, Contacts, and resource assignments explicitly.
- Normalize dates, identifiers, addresses, statuses, labor, parts, and file metadata.
- Keep tenant-specific and environment-specific mappings versioned.
- Use validation expressions for required fields and allowed value combinations.
Objective
Enforce configured status transitions, field ownership, deduplication, file policies, and target acceptance rules before making changes.
Instructions in Martini
- Confirm tenant-specific meanings for statuses such as Completed, Closed, or Canceled.
- Use stable ServiceMax or Salesforce identifiers as external keys.
- Distinguish business rejections from authentication, throttling, and server errors.
- Apply file-size, content-type, authorization, and duplicate policies to attachments and photos.
Common ServiceMax data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Work Orders | Represent service work, including status, priority, dates, customer, location, assigned resources, labor, parts, and completion information. | SAP S/4HANA, Oracle ERP Cloud, NetSuite, ServiceNow, Snowflake | Martini retrieves changes through REST or Salesforce APIs, resolves related objects, maps fields and statuses, applies validation, and performs idempotent target updates. |
| Service Requests | Capture customer-reported or internally created requests that may lead to service activity. | Salesforce, ServiceNow, Microsoft Dynamics 365, customer portals | Martini can synchronize request details, priority, ownership, and lifecycle status, using event notifications when available or modified-date polling otherwise. |
| Installed Products | Represent customer-owned or installed equipment and assets requiring service. | Salesforce, SAP S/4HANA, Microsoft Dynamics 365, Snowflake | Martini maps asset identifiers, account relationships, locations, and lifecycle data while preserving stable external keys. |
| Accounts | Represent customers, organizations, or service locations associated with field activity. | Salesforce, Microsoft Dynamics 365, SAP S/4HANA, Oracle ERP Cloud | Martini applies ownership and deduplication rules, transforms addresses and identifiers, and supports create-or-update synchronization. |
| Contacts | Represent people associated with customer Accounts, Installed Products, or Service Requests. | Salesforce, ServiceNow, Microsoft Dynamics 365, customer communication platforms | Martini validates account relationships and contact fields, maps communication preferences where available, and prevents duplicate creation. |
| Service Teams / Technicians | Represent field resources involved in scheduling, dispatch, and execution of Work Orders. | Salesforce, scheduling applications, Snowflake, ERP platforms | Martini can synchronize resource identifiers and assignments, cache relatively static reference data, and avoid excessive nested API calls. |
Authentication and security considerations
Authentication depends on the API surface
Salesforce-based ServiceMax deployments commonly use OAuth 2.0, connected applications, scopes, bearer tokens, and Salesforce user, profile, permission-set, and object-level access controls. ServiceMax-specific APIs may impose additional authentication and authorization requirements.
Protect credentials and limit access
- Store client credentials, refresh tokens, and API secrets in Martini secrets or environment configuration.
- Use separate credentials for development, test, and production.
- Request only the permissions required by each workflow.
- Confirm token expiration, refresh behavior, API version, and tenant-specific permissions before implementation.
Operational considerations for ServiceMax integrations
Quotas, pagination, and checkpoints
Confirm ServiceMax and Salesforce API quotas, use the documented pagination model, and persist continuation state and successful synchronization watermarks. Apply bounded batches and overlap windows for incremental extraction.
Idempotency and status rules
Use stable source identifiers and deterministic upserts. Status values and allowed transitions may be tenant-configured, so validate them rather than hard-coding assumptions about Completed, Closed, or Canceled.
Retries and observability
Use exponential backoff for throttling and transient server responses, while routing validation and authorization failures to an exception path. Preserve request identifiers, HTTP status codes, permitted response details, correlation identifiers, and workflow logs.
Schema and file changes
Expect custom fields, relationships, API-version differences, and changes to file storage. Test metadata and binary transfers separately, enforce file-size and MIME policies, and monitor for deprecated fields or incomplete event delivery.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than API calls
ServiceMax integrations often combine REST retrieval, related-object resolution, status rules, file handling, target writes, checkpoints, and reconciliation. Martini provides workflows for coordinating these steps instead of leaving behavior distributed across scripts.
Maintain reusable integration assets
Martini can expose normalized APIs, reuse mappings and workflow logic, and keep authentication and environment configuration separate from implementation. This helps isolate ServiceMax tenant-specific models from downstream applications.
Operate reliably
Martini supports scheduled and event-driven processing, conditional routing, validation, retries, exception handling, and workflow observability. These capabilities make it easier to distinguish transient API failures from business rejections and to recover from missed events or partial transfers.
Frequently asked questions
ServiceMax can be integrated primarily through REST APIs, including Salesforce REST APIs in Salesforce-based deployments. Selected deployments may also provide Salesforce Platform Events, Change Data Capture, outbound messages, or other callbacks, while bulk APIs, scheduled synchronization, and file or attachment endpoints can support high-volume and document-oriented use cases. Exact resources and event coverage depend on the product edition and tenant configuration.
Yes. Martini can integrate with ServiceMax by consuming documented ServiceMax or Salesforce REST APIs, receiving supported callbacks, using scheduled incremental workflows, processing bulk or asynchronous operations where available, and handling verified file endpoints. Martini can map ServiceMax objects, apply business rules, and write results to enterprise applications.
No dedicated ServiceMax connector is required. Martini can use ServiceMax's confirmed native integration mechanisms, including REST APIs, Salesforce-based APIs, supported callbacks, scheduled synchronization, documented SOAP services where applicable, and file endpoints. A native Martini ServiceMax connector is not confirmed in the supplied documentation.
Lonti does not charge an additional per-connector or per-vendor fee to integrate ServiceMax. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from ServiceMax, Salesforce, cloud infrastructure, target applications, or other third-party systems depending on subscriptions, usage, licensing, and deployment model.
REST APIs are the primary starting point. Salesforce Bulk or asynchronous APIs may be appropriate for large Salesforce-based ServiceMax datasets, while event or callback mechanisms can support selected real-time use cases after object coverage and delivery behavior are confirmed. SOAP should be treated as limited or product-specific until the target deployment documents it. No current ServiceMax GraphQL API was confirmed.
Some ServiceMax and Salesforce-based deployments may support Platform Events, Change Data Capture, outbound messages, or other callbacks, but availability is object- and tenant-dependent. Confirm whether the notification contains a full object or only an identifier, along with replay and retry behavior. Martini can receive supported callbacks and supplement them with scheduled REST reconciliation.
Martini can use stable ServiceMax or Salesforce identifiers as external keys, persist watermarks or change tokens, apply overlap windows, and perform deterministic create-or-update operations. Workflows can record source-to-target identifiers, classify rejected records, and retry transient failures without creating duplicate Work Orders, Service Requests, attachments, or status updates.
Yes. Martini can expose a controlled API that presents a normalized contract to downstream applications while it retrieves or updates ServiceMax through the documented REST or Salesforce API surface. This can isolate consumers from tenant-specific object names, authentication details, relationship structures, and future mapping changes.
Related Martini documentation
APIs
Connect ServiceMax with your enterprise systems
Use Martini to build maintainable ServiceMax integrations with secure API access, orchestrated workflows, data transformation, event handling, and reliable synchronization.