.png)
IFS Field Service Management Integration Guide
Integrate IFS Field Service Management with enterprise applications through IFS Cloud REST APIs, configured outbound events, scheduled synchronization, and secure workflow orchestration.
IFS Field Service Management integration options at a glance
IFS Field Service Management, delivered through IFS Cloud, primarily integrates through REST APIs exposed by business projections and related resources. These APIs can query and modify service requests, work orders, assignments, resources, customers, and sites, although available operations depend on the release, enabled modules, and tenant configuration. Selected areas may support outbound events or callback-style integrations, but coverage is object- and configuration-dependent. Martini can also orchestrate paginated and incremental REST synchronization, controlled batch processing, and API façade patterns. OAuth 2.0 is recommended where enabled, while Basic Authentication may remain available for selected legacy configurations. Attachment and SOAP support should be verified for the target environment.
| Integration point | Supported by IFS Field Service Management? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | IFS Cloud exposes REST APIs through business projections and related resources for querying and modifying Service Requests, Work Orders, Assignments, Resources, Customers, and Sites. Exact endpoints and operations depend on the release and tenant configuration. | Martini can consume IFS REST APIs, generate reusable integration assets from API definitions where available, map payloads, apply business rules, and expose REST APIs for external applications. |
| Webhooks / outbound callbacks | Limited | IFS Cloud supports event-driven and outbound integration capabilities in selected areas. Coverage depends on the release, enabled business events, configured event actions, projection, object, and tenant security. | Martini can expose a controlled webhook endpoint and process selected IFS notifications. Where the required event is unavailable, Martini can use scheduled incremental REST polling. |
| Bulk / async / batch APIs | Limited | Collection operations or batch-oriented processing may be available for selected projections. Page sizes, transaction behavior, concurrency, and request limits are endpoint-specific. | Martini can orchestrate paginated REST calls, controlled batches, checkpoints, throttling, and reconciliation workflows without assuming a dedicated bulk API. |
| File / attachment APIs | Limited | Documents, attachments, or technician evidence may be available for selected IFS objects, including service-related records. Upload, download, metadata, content limits, and permissions must be verified per object. | Martini can call documented content and metadata endpoints, transform metadata, transfer files, and route attachment failures for review. |
| SOAP APIs | Legacy | Older IFS products, deployments, or integration configurations may expose SOAP or other legacy service interfaces. SOAP should not be assumed for new IFS Cloud integrations. | Martini can consume SOAP services when the target IFS environment exposes and authorizes them, while REST remains the preferred starting point for new designs. |
| Authentication | Yes | IFS Cloud security and identity configuration supports authenticated API access. OAuth 2.0 should be verified for the target tenant; selected legacy configurations may support Basic Authentication. | Martini can store client credentials, tokens, endpoint settings, and other environment-specific secrets securely and use authenticated API workflows. |
| Database / analytics access | Not confirmed | Direct database access is not the preferred integration method for cloud-hosted IFS Field Service Management. Supported APIs, projections, events, reports, or exports should be used instead. | Martini can connect to databases when an explicitly supported deployment requires it, but it should not bypass IFS APIs without customer and vendor confirmation. |
How IFS Field Service Management exposes data and business events
IFS REST APIs
IFS Cloud REST APIs exposed through business projections are the primary mechanism for reading and changing Field Service Management data. They can support Service Requests, Work Orders, Assignments, Resources, Customers, Sites, and other enabled objects, with exact operations determined by the tenant and release.
Martini implementation pattern
Martini implementation pattern: Martini authenticates to the configured IFS endpoint, invokes the required projection resource, handles pagination and response validation, maps the result into a canonical model, and calls downstream APIs or exposes a controlled response API.
Implementation sequence
IFS outbound events and callbacks
IFS Cloud supports event-driven and outbound integration capabilities in selected areas, but event coverage is not uniform across Field Service Management objects. Availability depends on enabled business events, configured actions, projections, release, and security.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured webhook endpoint for configured IFS notifications, validates the event and correlation data, retrieves the current IFS object when necessary, and routes the normalized change to target applications. Polling remains the fallback where an event is unavailable.
Implementation sequence
Scheduled incremental synchronization
When an outbound event is unavailable for a required Service Request, Work Order, Assignment, or Resource change, IFS REST APIs can be queried on a schedule using a modified timestamp, status, version, or other supported incremental filter.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow reads the last successful checkpoint, requests filtered and paginated IFS data, processes records in controlled batches, and advances the checkpoint only after successful downstream handling.
Implementation sequence
Common IFS Field Service Management integration patterns
Pattern 1: Create IFS work orders from CRM requests
When to use this pattern
Use this pattern when Salesforce or Microsoft Dynamics 365 captures the customer request while IFS Field Service Management owns field execution. It resolves related Customers and Sites, applies priority and serviceability rules, and creates the appropriate IFS Service Request or Work Order with a durable cross-reference.
Integration direction
Example Mapping
| IFS Field Service Management Field | Canonical Field | Target Field |
|---|---|---|
| externalRequestId | sourceRequestId | externalReference |
| accountId | customerIdentifier | Customer |
| serviceAddress | siteAddress | Site |
| priority | servicePriority | Priority |
Martini implementation pattern
Martini receives a CRM event or API request, validates required fields, resolves IFS Customer and Site identifiers, transforms dates and status values, calls the configured projection, and returns the IFS identifier. Duplicate checks, business-rule rejections, transient retries, and dead-letter handling protect against repeated Work Orders.
Martini capabilities used
- workflows
- API consumption
- API exposure
- data mapping
- business rules
- error handling
Pattern 2: Synchronize assignments and work order status
When to use this pattern
Use this pattern when downstream applications need technician, schedule, progress, completion, or service-result information. It supports event-driven processing where the IFS tenant exposes the required events and scheduled incremental polling where event coverage is incomplete.
Integration direction
Example Mapping
| IFS Field Service Management Field | Canonical Field | Target Field |
|---|---|---|
| WorkOrderId | workOrderIdentifier | WorkOrderReference |
| AssignmentStatus | fieldExecutionStatus | ServiceStatus |
| ResourceId | technicianIdentifier | AssignedTechnician |
| ScheduledStart | scheduledStartTime | AppointmentStart |
Martini implementation pattern
Martini receives a selected outbound notification or queries IFS using a modified-date filter, retrieves the current Work Order and Assignment state, maps IFS lifecycle values to the target model, and updates downstream systems. Checkpoints, correlation identifiers, and retries support reliable incremental delivery.
Martini capabilities used
- event-driven workflows
- scheduled workflows
- API consumption
- data mapping
- status transformation
- checkpointing
- error handling
Pattern 3: Coordinate parts and service completion with an ERP
When to use this pattern
Use this pattern when IFS field execution must be coordinated with SAP S/4HANA or Oracle NetSuite for parts, inventory, products, completion, or billing inputs. It is appropriate where related master data and company or site context must be validated before posting transactions.
Integration direction
Example Mapping
| IFS Field Service Management Field | Canonical Field | Target Field |
|---|---|---|
| PartNumber | itemIdentifier | Material |
| QuantityConsumed | consumedQuantity | Quantity |
| Site | serviceLocation | Plant |
| WorkOrderStatus | completionStatus | ServiceConfirmationStatus |
Martini implementation pattern
Martini retrieves eligible IFS completion or consumption data, resolves item and organizational identifiers, transforms units and statuses, applies approval and duplicate rules, and submits the ERP transaction. Validation failures are separated from transient API failures, with retry and reconciliation paths for uncertain outcomes.
Martini capabilities used
- workflows
- API consumption
- data transformation
- business rules
- idempotency controls
- retry handling
- reconciliation
Pattern 4: Publish controlled service visibility to customers
When to use this pattern
Use this pattern when a customer portal, Microsoft Teams, or another external application needs appointment, technician assignment, arrival, or completion information without direct access to IFS Cloud. The workflow exposes only the approved fields and applies customer-specific visibility rules.
Integration direction
Example Mapping
| IFS Field Service Management Field | Canonical Field | Target Field |
|---|---|---|
| WorkOrderNumber | serviceReference | MessageReference |
| AssignmentStatus | customerVisibleStatus | NotificationStatus |
| ScheduledArrivalWindow | arrivalWindow | MessageContent |
| SiteAddress | serviceLocation | MessageLocation |
Martini implementation pattern
Martini receives an approved IFS event or detects a changed object through polling, retrieves current details, removes restricted fields, applies notification rules, and invokes the target application API. Failed notifications are retried without repeating successful deliveries by using a notification key.
Martini capabilities used
- API exposure
- scheduled workflows
- event processing
- data filtering
- business rules
- secure configuration
- error handling
Applications commonly integrated with IFS Field Service Management
IFS Field Service Management can be connected to customer, enterprise resource planning, service management, collaboration, commerce, and analytics applications. The exact integration should be based on the APIs, projections, events, and security configuration available in the customer’s IFS Cloud tenant.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer service requests, account and contact context, work order progress, assignments, and field-service outcomes. | Salesforce → Martini → IFS Field Service Management | Martini receives a Salesforce event or API request, resolves the IFS Customer and Site, maps service details and priority, calls the relevant IFS projection, and returns or stores the IFS identifier. A separate incremental workflow can publish work order and assignment status back to Salesforce. |
| Microsoft Dynamics 365 | Coordinate customer, case, sales, and service information with IFS field operations. | Microsoft Dynamics 365 → Martini → IFS Field Service Management | Martini validates Dynamics payloads, applies lifecycle and identifier mappings, creates or updates IFS Service Requests or Work Orders, and synchronizes IFS status and assignment changes back through controlled API calls. |
| SAP S/4HANA | Exchange customers, products, inventory, parts consumption, billing inputs, and completed service transactions. | SAP S/4HANA → Martini → IFS Field Service Management | Martini orchestrates master-data lookups and work order completion flows, transforms SAP material and organizational identifiers into IFS values, applies duplicate checks, and routes rejected transactions for reconciliation. |
| Oracle NetSuite | Synchronize customer, item, service, fulfillment, and financial information associated with field work. | Oracle NetSuite → Martini → IFS Field Service Management | A Martini workflow consumes approved NetSuite changes, resolves related IFS Customers, Sites, and Parts, calls the appropriate IFS REST resources, and sends completion or exception results back to NetSuite. |
| ServiceNow | Exchange incidents or customer-facing service requests with IFS field execution status. | ServiceNow → Martini → IFS Field Service Management | Martini maps ServiceNow requests to IFS Service Requests or Work Orders, stores cross-references, and uses events where available or scheduled incremental queries to update ServiceNow with assignment, progress, and completion details. |
| Microsoft Teams | Notify dispatchers, technicians, and operational teams about assignments, appointments, and status changes. | IFS Field Service Management → Martini → Microsoft Teams | Martini receives a configured IFS event or detects changes through scheduled polling, applies notification rules, formats a concise operational message, and sends it to the appropriate Teams destination through its available API. |
| Shopify | Pass product or order information to downstream service processes when installation or after-sales field service is required. | Shopify → Martini → IFS Field Service Management | Martini consumes relevant Shopify order information, validates the serviceable item and customer location, resolves IFS master data, and creates a Service Request or Work Order when business rules are satisfied. |
| Power BI | Publish work order, assignment, completion, and resource data for operational reporting. | IFS Field Service Management → Martini → Power BI | Martini retrieves changed IFS objects through paginated REST queries, normalizes statuses and timestamps, writes the reporting payload to the approved Power BI ingestion path or reporting store, and records checkpoints for repeatable loads. |
How to build a IFS Field Service Management integration in Martini
Objective
Establish access to the target IFS Cloud tenant and the downstream systems using tenant-specific endpoints, roles, permissions, and authentication settings.
Instructions in Martini
- Confirm the IFS Cloud release, enabled projections, and API catalog
- Verify OAuth 2.0 settings, scopes, roles, and permissions; use Basic Authentication only where explicitly supported
- Store client credentials, tokens, and endpoints as Martini environment secrets
- Test access with the production-equivalent integration identity
Objective
Select an event-driven, API-led, or scheduled entry point based on the IFS objects and events available in the target tenant.
Instructions in Martini
- Use a Martini API for inbound service requests or controlled façade access
- Use a secured webhook endpoint for configured IFS outbound events
- Use a Scheduler Trigger for objects without adequate event coverage
- Define the incremental timestamp, status, version, or checkpoint strategy
Objective
Receive the source payload or retrieve current IFS data while accounting for pagination, incomplete notifications, and related-object dependencies.
Instructions in Martini
- Validate incoming event signatures or authentication context where configured
- Retrieve the current Service Request, Work Order, Assignment, Resource, Customer, or Site when required
- Use server-side filters and pagination for collection queries
- Preserve source identifiers, correlation IDs, and response metadata
Objective
Coordinate lookups, transformations, target calls, business rules, and response handling in a maintainable Martini workflow.
Instructions in Martini
- Resolve dependent Customers, Sites, Resources, Parts, or company context
- Branch for create, update, cancellation, completion, and rejection scenarios
- Sequence calls where IFS object relationships require master data first
- Use reusable services or workflows for shared validation and cross-reference logic
Objective
Convert IFS projection payloads into canonical and target-specific models without assuming that IFS statuses, identifiers, dates, or relationships map one-to-one.
Instructions in Martini
- Map IFS fields to the canonical integration model
- Normalize timestamps, time zones, addresses, coordinates, units, and status values
- Transform JSON or other supported payload structures as required
- Validate required fields and reject incomplete business messages before target submission
Objective
Ensure only valid, authorized, and actionable service transactions are written to downstream systems or IFS Cloud.
Instructions in Martini
- Apply company, site, customer, serviceability, and approval rules
- Check external references before creating Work Orders or Service Requests
- Use stable correlation identifiers and cross-reference storage
- Route business-rule failures separately from transient technical failures
Common IFS Field Service Management data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Service Requests | Capture customer-reported or internally generated requests for service and initiate downstream field-service processing. | Salesforce, Microsoft Dynamics 365, ServiceNow, customer portals | Martini validates customer and site references, maps request details and priority, creates or updates the IFS object through the relevant projection, and stores correlation identifiers. |
| Work Orders | Represent planned or executed work associated with service delivery. | Salesforce, ServiceNow, SAP S/4HANA, Oracle NetSuite, reporting platforms | Martini synchronizes work order lifecycle data, applies explicit status mappings, handles related master-data dependencies, and uses idempotency or cross-reference checks before retries. |
| Assignments | Allocate work to a field resource, technician, crew, or schedule. | Salesforce, Microsoft Teams, customer portals, workforce applications | Martini maps resource, schedule, appointment, and status information and uses configured events or incremental polling to publish assignment changes. |
| Resources | Represent technicians, employees, crews, equipment, or other dispatchable resources. | CRM platforms, workforce applications, analytics stores | Martini synchronizes approved resource attributes, normalizes identifiers and availability-related fields where exposed, and preserves the IFS source identifier. |
| Customers | Identify organizations or individuals receiving field service. | Salesforce, Microsoft Dynamics 365, SAP S/4HANA, Oracle NetSuite | Martini resolves or synchronizes customer master data before creating dependent Service Requests or Work Orders and applies duplicate and ownership rules. |
| Sites | Represent customer locations, service addresses, assets, or operational locations. | CRM platforms, ERP systems, customer portals, mapping and reporting stores | Martini maps addresses, site identifiers, company context, and geographic data, validating that dependent Work Orders and Assignments reference an authorized site. |
Authentication and security considerations
Tenant-specific authentication
IFS Cloud authentication and authorization depend on the target tenant’s IFS security and identity configuration. OAuth 2.0 is recommended for system-to-system integrations where enabled, while Basic Authentication may remain available for selected legacy configurations.
Permissions and secrets
Access to projections, operations, companies, sites, and business objects is controlled by IFS roles and permissions. Martini should store client IDs, client secrets, tokens, endpoint URLs, and other environment-specific values as secure secrets rather than embedding them in workflows.
Transport and API exposure
Use HTTPS for IFS API communication and expose only the Martini API operations required by external systems. Apply authentication and authorization to inbound Martini APIs and webhook endpoints, and limit payloads to approved service data.
Operational considerations for IFS Field Service Management integrations
Release and projection differences
IFS APIs vary by Cloud release, enabled modules, configured projections, and tenant security. Confirm endpoint definitions, fields, operations, and permissions before finalizing mappings.
Pagination, limits, and concurrency
Use server-side filtering and pagination for large Work Order, Assignment, and Service Request collections. Apply controlled concurrency, backoff, and retry policies based on the tenant or gateway limits.
Idempotency and reconciliation
Use stable external identifiers or integration cross-references for create operations. A timeout does not prove that IFS rejected a request, so query or reconcile before retrying.
Events and schema changes
Confirm which objects and fields generate outbound events. Version mappings, validate required fields, and monitor for projection or response changes between releases.
Related objects and field data
Work Orders and Assignments may depend on Customers, Sites, Resources, Parts, company context, time zones, addresses, and geographic data. Validate these relationships before submission.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini coordinates IFS API calls, related-object lookups, target-system updates, business rules, and response handling in maintainable workflows rather than scattering logic across scripts.
Reliable synchronization
Event-driven and scheduled patterns can coexist. Martini supports pagination, checkpoints, controlled batches, retries, structured errors, and reconciliation for tenant-specific event coverage and API behavior.
Reusable integration assets
Teams can expose controlled APIs, reuse validation and transformation logic, and keep environment-specific endpoints and credentials outside application code. This supports consistent deployment and easier maintenance as IFS projections evolve.
Frequently asked questions
IFS Field Service Management is delivered through IFS Cloud and primarily integrates through REST APIs exposed by business projections. Selected areas may also support outbound events or callbacks, while scheduled incremental REST synchronization can be used where event coverage is incomplete. SOAP, attachments, and batch capabilities depend on the target release and tenant configuration.
Yes. Martini can consume IFS Cloud REST APIs for Service Requests, Work Orders, Assignments, Resources, Customers, and Sites. It can also receive selected IFS event notifications or callbacks, expose APIs for external applications, schedule incremental synchronization, map data, and apply validation, retry, and reconciliation logic.
No dedicated IFS connector is required. Martini can integrate using IFS Cloud’s confirmed native mechanisms, primarily REST APIs and, where configured, outbound events or callbacks. The exact workflow depends on the IFS release, enabled projections, permissions, and tenant configuration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate IFS Field Service Management. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from IFS, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs through IFS Cloud business projections are the preferred starting point. Configured outbound events can be used for selected objects and changes, while scheduled filtered queries are appropriate when event coverage is unavailable. SOAP may exist in older deployments but is a legacy option, and no verified IFS GraphQL API was identified.
IFS Cloud supports event and outbound integration capabilities in selected areas, but coverage is not universal across Service Requests, Work Orders, Assignments, Resources, or attachments. Confirm the required event, projection, and configuration in the target tenant. Martini can receive supported notifications or use scheduled incremental REST polling as a fallback.
Martini can use event-driven workflows or scheduled workflows with server-side filters, pagination, and checkpoints. It maps IFS projection fields into canonical and target-specific models, normalizes statuses and timestamps, resolves related Customers and Sites, and applies business rules before writing to downstream systems.
OAuth 2.0 should be verified and configured where enabled, with client credentials, tokens, endpoints, and other secrets stored securely in Martini. Workflows can distinguish authentication, validation, business-rule, concurrency, and transient failures; apply controlled retries; log correlation IDs; and use external references or cross-reference checks to prevent duplicate Work Orders.
Related Martini documentation
APIs
Workflows
Reliability
Integrate IFS Field Service Management with Martini
Use Martini to connect IFS Cloud field-service operations with enterprise applications through secure APIs, configured events, scheduled synchronization, data mapping, and reliable workflow orchestration.