Contents

1. Introduction & Business Context
2. Why Multi-Company?
3. How It Works — The Big Picture
4. Step-by-Step Configuration Guide
5. Controlling the FSM Planning Board
6. Extensibility
7. Monitoring & Error Recovery
8. Summary

SAP S/4HANA Plant Maintenance (PM) and SAP Field Service Management (FSM) are designed to work together as one end-to-end maintenance execution platform. When a planner raises a PM order in S/4HANA — for a breakdown repair, a preventive inspection, or a scheduled overhaul — that order is automatically pushed to FSM, where a dispatcher assigns it to the right field technician. The technician receives the work on their mobile device, executes it on-site, and the completion confirmation flows back to S/4HANA —

closing the loop without manual re-entry.

A companion blog post covers this integration for organisations with a single FSM company. This blog addresses a more common enterprise scenario: a single SAP system serving multiple business units, regions, or subsidiaries, each managed by a separate FSM company.

2. Why Multi-Company?

    SAP FSM supports a single-company model where all field service data lives in one place.
    While authorizations can be used to restrict what each country or business unit user sees,
    this still means all their data — customers, orders, technicians, activities — is loaded
    into and managed within that single company. For many enterprises this is not desirable:
    different subsidiaries may have different contracts, different service processes, different
    FSM configurations, or strict data segregation requirements. Multi-company support
    allows organisations to segregate their business and data into separate FSM companies,
    each operating independently with its own configuration, workforce, and dispatching logic —
    while still being driven from a single S/4HANA system.
 

    Beyond data segregation, multi-company support also enables:
 

3. How It Works — The Big Picture

    Every time a PM order is released and saved in S/4HANA — on creation or any subsequent
    update — the system evaluates whether and where to replicate it to FSM. The steps are:
 

Note:  Why asynchronous? Replication happens in the background via a queue —
    it does not hold up the PM order save transaction. Planners experience no delay;
    the FSM API call is processed independently after the order is committed in S/4HANA.

4. Step-by-Step Configuration Guide

    Configuration lives in two places in SPRO (transaction SPRO😞
 

• Multi-company routing (Steps 1–5) is maintained via a single SPRO node that
        opens a view cluster. All sub-views are navigated through the
        Dialog Structure panel on the left-hand side of the screen.
       
  SPRO Node: Service → Integration with Other SAP Solutions → SAP Field Service Management →
  Configure Multiple Company Replication
          
• Code-list mappings & region (Steps 6–7) are direct child nodes under
        a separate path with no additional grouping:
       
         SPRO Node: Plant Maintenance and Customer Service → Integration with SAP Field Service Management 

4.1. Define S/4 FSM Companies

      Create a logical identifier for each FSM company you want to replicate to. This short key
      — for example COMP_NORTH or COMP_SOUTH — becomes the
      master reference that all subsequent configuration links back to:
      FSM account details, plant assignments, filter rules, and code-list mappings all
      reference this identifier.
   

SPRO:  Configure Multiple Company Replication → Dialog Structure:Define S/4HANA FSM Company

4.2. Assign FSM Account & Company Details

      For each S/4 FSM Company ID, enter the technical identifiers from your FSM tenant.
      These are found in the FSM Admin portal under
      Account → Account Information and Account → Companies.
   

SPRO:  Configure Multiple Company Replication → Dialog Structure: Define S/4HANA FSM Company →Assign FSM Company Details

Note:  RFC destination is shared across all companies: The FSM Account ID
      and Company ID configured here are sent as HTTP request headers and can differ per S/4 FSM
      Company. However, the underlying RFC destination — which defines the FSM
      endpoint URL and OAuth profile — is always read from the global configuration
      ( CRMC_FSM_CONFIG ) and cannot be varied per company, either through the
      multi-company table or through the BAdI. This means all S/4 FSM companies must
      reside within the same FSM tenant — they are separate companies within one
      account, not companies on different FSM endpoints.

4.3. Assign Rule Type to the PM Replication Object

      Specify how the system determines which FSM company a PM order is routed to.
      The rule type is a configuration value that tells the system which routing strategy to
      apply. Two rule types are supported for PM orders:
   

Set the Replication Object = PM and select the appropriate rule type.

SPRO:  Configure Multiple Company Replication → Dialog Structure:Assign Rule Type to Replication Object

4.4. Enable PM Replication per Company

      For each S/4 FSM Company ID, activate PM order replication by adding the
      replication object PM. This acts as a
      per-company master switch — if a company does not have PM enabled here,
      no PM orders will ever be routed to it, regardless of the plant configuration in Step 4.
   

SPRO:  Configure Multiple Company Replication → Dialog Structure:Assign Replication Object Details

4.5. Assign Relevant Plants — Rule Type 01 Only

      For plant-based routing, define which combination of S/4 FSM Company +
      Planning Plant + Order Type should route PM orders to which FSM company.
      This is the core routing table.
   

Important:  This routing configuration is maintained here under the multi-company replication IMG node. It is a separate entry point from the   single-company plant filter and must not be confused with it.

SPRO:  Configure Multiple Company Replication → Dialog Structure: Assign Replication Object Details →Assign Relevant Plants

4.6. Configure Code-List Mappings & Filters

      SAP PM and FSM use different codes for the same business concepts. All configuration
      in this step uses SPRO node:
   

SPRO:  Plant Maintenance and Customer Service →Integration with SAP Field Service Management

Each item below corresponds to a separate child node in this path.

4.6.1. Define System Status to filter Maintenance Order replication

      Configure which S/4 system statuses should trigger or
      block replication for each company and order type. Each subsidiary
      independently decides at which point in the PM lifecycle orders flow to FSM.
   

SPRO:  Integration with SAP Field Service Management →Define System Status to filter Maintenance Order replication

4.6.2 Configure Mapping for Status Codelist

      Translates S/4 system statuses to FSM Service Call status codes. When multiple
      active statuses match simultaneously, the entry with the
      lowest configured priority number is applied.
      Example: S/4 Released → FSM status –2 (Ready to Plan).
   

SPRO:  Integration with SAP Field Service Management →Configure Mapping for Status Codelist

4.6.3. Configure Mapping for Service Call Type Codelist

      Maps the S/4 order type (e.g. PM01, PM02) to the FSM
      Service Call Type (e.g. Maintenance, Repair, Inspection).
      This determines how work is categorised in FSM and affects which service call
      templates and follow-up workflows are triggered.
   

SPRO:  Integration with SAP Field Service Management →Configure Mapping for Service Call Type Codelist

4.6.4. Configure Mapping for Problem Type Codelist

      Maps the S/4 maintenance activity type (e.g. Electrical, Mechanical,
      Preventive) to the FSM Problem Type. This helps dispatchers instantly
      understand the nature of the job and assign a technician with the right skill set.
   

SPRO:  Integration with SAP Field Service Management →Configure Mapping for Problem Type Codelist

4.6.5. Configure Mapping for Priority Codelist

      Maps S/4 PM priority codes to FSM priority values (HIGH, MEDIUM, LOW). A separate
      Emergency Priority field is also available — when an emergency order
      is processed (identified by its processing context), this value overrides the standard
      priority mapping, ensuring urgent work is immediately visible to the FSM dispatcher.
   

SPRO:  Integration with SAP Field Service Management →Configure Mapping for Priority Codelist

4.6.6. Set Default Business Partner (Customer)

      Defines a fallback customer (Business Partner) per FSM company, used when the PM order
      does not carry a Ship-To party. FSM requires a business partner on every Service Call,
      so this default prevents replication failures for orders that have no customer reference.
   

SPRO:  Integration with SAP Field Service Management →Set Default Business Partner (Customer)

4.6.7. Configure Region

      In FSM, a Region links each Activity to a geographical or organisational
      area, which drives scheduling availability, resource pooling, and address resolution.
      For PM integration, the region code is derived from S/4HANA data and included in
      every Activity sent to FSM. The source of that region code is configurable
      per FSM company, giving each subsidiary the flexibility to align
      the region model to how they have structured FSM.
   

SPRO:  Integration with SAP Field Service Management →Configure Region

5. Controlling the FSM Planning Board

    When a PM order arrives in FSM it lands on one of two planning boards, depending on how
    the filter rule was configured in Step 6. This determines how the dispatcher interacts
    with the work before a technician is assigned.
 

6. Extensibility

    When rule type 07 (Custom Logic) is configured for the PM replication
    object, the system invokes BAdI CRMS4_FSM_RELV_COMP_DETERM to determine
    which FSM company and account a PM order should be routed to. This gives full programmatic
    control over company routing for scenarios that cannot be handled by plant and order type
    alone.
 

BAdI: CRMS4_FSM_RELV_COMP_DETERM

Method: DETERMINE_RELVNT_COMP

When to implement

    Use this BAdI when the target FSM company cannot be resolved from planning plant and order
    type alone. Common examples:
 

• Routing based on a functional location hierarchy — e.g. all orders
          under a specific FL node go to a specific FSM company regardless of plant
• Routing based on a custom partner function or responsible person on
          the PM order
• Routing determined by an external system lookup or custom Z-field
• Complex multi-level routing logic that changes dynamically at runtime

How it works

    The BAdI is called inside the replication class.
    Before the BAdI is called, any company and account values already resolved by the standard
    plant-based lookup are cleared. This means the BAdI has full responsibility
    for the result — it completely overrides the standard determination.
 

    The BAdI is retrieved with a filter on replication object PM,
    so a single enhancement spot can hold separate implementations for PM orders, Service Orders,
    Equipment, and other replication objects — each triggered independently without interference.
 

Interface

Important:  Important: If CT_RELEVANT_COMP is left empty or an exception
    is raised, replication is silently skipped for that order — no error is
    written to AIF. Always ensure your implementation populates at least one row with a valid
    FSM Company ID and Account ID.

7. Monitoring & Error Recovery

    Every replication attempt — successful or failed — is recorded in SAP's
    Application Interface Framework (AIF). This gives operations
    teams complete visibility into what was sent to FSM, what FSM responded,
    and the ability to restart any failed message after the root cause is resolved —
    all without developer involvement.
 

From the AIF monitor, teams can:

• See exactly which PM orders were replicated and when
• Inspect the full message payload sent to FSM and the FSM response received
• Restart failed messages with a single action — for example after a
          missing region in FSM has been created, or a connectivity issue has been resolved
• Receive automatic alerts when errors occur, via configurable
          recipient groups — ensuring nothing fails silently

8. Summary

    Multi-company PM FSM integration enables enterprises to run a unified SAP system while
    keeping each business unit's field service operations fully independent. Here is
    what it delivers at a glance:
 

References