Contents
- What Problem Does This Solve?
- The Two Directions — Plain Language
- Key Configuration: Mapping Template Elements to Service Order Fields
- Multi-Company Replication
- What Gets Stored in S/4HANA
- The Element Type Model
- The CDS View Layer
- OData APIs and Processing Classes
- Extensibility for Customers
- Monitoring
- Authorization
- Summary — What This Means for the Business
1. What Problem Does This Solve?
Field service technicians in SAP Field Service and Asset Management (SAP FSA) use checklists every day — to follow safety protocols, document inspections, record equipment readings, and confirm completed work steps. Until recently, all that structured data stayed inside FSA. It was never visible to back-office teams in SAP S/4HANA Public Cloud, and back-office teams had no way to push context-rich, prefilled checklists out to the field before a technician even arrived on site.
The Checklist Integration feature closes both gaps:
Direction | What it enables |
FSA → S/4HANA | Checklist templates and completed instances created in FSA are replicated into S/4HANA Public Cloud, where the data can be used for analytics and KPI reporting. |
S/4HANA → FSA | When a service order line item is released in S/4HANA, a prefilled checklist instance is automatically created and pushed to FSA — attached to the right FSA activity. |
2. The Two Directions — Plain Language
Direction 1 — Completed Work Coming Back (FSA → S/4HANA)
A technician finishes a job and closes the checklist in FSA. At that point:
- FSA fires an event — checklistinstance.closed or checklistinstance.deleted for instances; checklisttemplate.activated / checklisttemplate.deactivated for templates.
- The FSA Connector packages the data and routes it through SAP Cloud Integration via dedicated iFlows.
- The iFlow calls an OData V4 API endpoint on S/4HANA via SAP Cloud Connector.
- S/4HANA decodes the Base-64 encoded ZIP payload, parses the XML inside, and stores the structured data in its own database tables.
FSA → FSA Connector → SAP Cloud Integration (iFlow) → SAP Cloud Connector → S/4HANA OData V4 API → Database tables
The checklist content arrives as a ZIP archive. For a template, the archive contains:
- template.xml — the form structure with all chapters and element definitions
- translations-<lang>.xml — language-specific labels, one file per language
- container_metadata.xml — metadata
For a completed instance, the archive contains the filled-in values in values-1-<language>.xml. The only link between instance values and template elements is the key attribute shared between the two XML files.
Direction 2 — Prefilled Checklists Going Out (S/4HANA → FSA)
A planner releases a service order line item in S/4HANA. The Data Exchange Framework then triggers a process that:
1. Eligibility check
The system verifies the line item is released, has an FSA activity associated, and does not already have a checklist instance. Items that fail any check are silently skipped.
2. Template determination
A BAdI (CRMS4_FSM_CHKLST_TMP_DETERMIN) is called with the full service header and all line items. The customer's implementation returns which checklist template to use for each service item. This step is mandatory — no checklist instance is created without a template ID.
3. Standard prefill from mapping table
The system reads the configuration table CRMC_FSM_SOTEL_M to determine which service order fields should fill which checklist elements. This is the no-code prefill path — covers the majority of requirements through simple table configuration.
4. Custom prefill logic (optional)
A second BAdI (CRMS4_FSM_CHKLST_TMP_ELMVAL_DT) is called, giving customers the ability to override or supplement any element value with their own logic.
5. Replication to FSA
The instance content is generated as a JSON payload and sent asynchronously to FSA via an OData client proxy. FSA associates the new checklist instance with the FSA activity for that line item. One service order line item produces exactly one checklist instance.
Why asynchronous? The FSA API call is processed in the background via a queue — it does not hold up the service order save transaction. Planners experience no delay, and errors are captured in AIF for review and restart.
3. Key Configuration: Mapping Template Elements to Service Order Fields
Table CRMC_FSM_SOTEL_M (Template Elements and Service Fields Mapping) is the heart of the prefill feature. Each row tells the system: “For this template element, use this service order field as the default value.”
Column | Meaning |
TEMPLATE_ID | Which checklist template this mapping applies to |
FSM_ELEMENT_ID | The element within that template to prefill |
TABLE_ROW_INDEX / SERIES_INDEX | Position in table or series type elements |
FIELDNAME | The service order field to use as the source value |
In S/4HANA Public Cloud, this table is maintained via Self-Service Configuration UI (SSCUI) under:
- Application Area: Field Service & Asset Management
- Sub-Application Area: Integration
- Item: Integration with Field Service & Asset Management
- Step: Prefill Checklist Instances
These SSCUIs are accessible via the Manage Your Solution Fiori app. Access requires the business role SAP_BR_BPC_EXPERT (Configuration Expert – Business Process Configuration) to be assigned to your user in the SAP S/4HANA Cloud system.
No code required for standard prefill. Most customers can cover their prefill requirements entirely through this mapping table. Only advanced scenarios — conditional logic, lookups from related objects, or derived calculations — need the BAdI implementation in Step 4.
4. Multi-Company Replication
Many SAP FSA customers run multiple FSA companies — often aligned to different regions, subsidiaries, or service organisations. The prefilled checklist instance must go to the right FSA company.
Scenario | How to configure |
Single company | Maintain the FSA Account ID and Company ID directly in the communication arrangement SAP_COM_0687. Leave the multi-company configuration table empty. |
Multiple companies | Maintain company determination rules in the SSCUI under Configure Multiple Company Replication. The system evaluates organisational data (sales area from service contracts) or a specific restriction field to select the correct FSA company for each service order line item. |
Both scenarios are supported with no code change. The SSCUI path for multi-company setup is:
- Application Area: Field Service & Asset Management
- Sub-Application Area: Integration
- Item: Integration with Field Service & Asset Management
- Step: Configure Multiple Company Replication
These SSCUIs are accessible via the Manage Your Solution Fiori app. Access requires the business role SAP_BR_BPC_EXPERT (Configuration Expert – Business Process Configuration) to be assigned to your user in the SAP S/4HANA Cloud system.
5. What Gets Stored in S/4HANA
Seven database tables in package CRMS4_FSM_CHECKLIST_INT on system ER1 hold all checklist data. Template and instance data are stored separately by design — this allows them to evolve independently and enables future analytics that join or compare them as needed.
Table | Content |
CRMD_FSM_TM_HDR | Template header — ID, name, status, version, default language, category |
CRMD_FSM_TM_HDRT | Template header texts — language-dependent descriptions |
CRMD_FSM_TM_ELM | Template elements — type, structure, properties, parent-child hierarchy, all type-specific attributes (min/max values, ranges, visibility conditions, …) |
CRMD_FSM_TM_ELMT | Template element texts — labels, titles, descriptions per language |
CRMD_FSM_IN_HDR | Instance header — instance ID, associated template, status, external ID, object type, request ID |
CRMD_FSM_IN_HDRT | Instance header texts — language-dependent descriptions |
CRMD_FSM_IN_ELM | Instance element values — the actual data filled in by the technician, including value type, series index, table row, attachments, images, and comments |
Three AIF index tables support message monitoring: CRMD_FSM_TMP_IDX (inbound templates), CRMD_FSM_INS_IDX (inbound instances), and CRMD_FSM_PFL_IDX (outbound prefill).
6. The Element Type Model
The integration maps FSA element type names (strings like “textinput”, “dropdown”, “signature”) to a structured S/4HANA domain (CRMS4_FSM_ELEMENT_TYPE) with short two-character codes. The mapping is maintained in table CRMC_FSM_ELMT_MP.
There are 21 element types supported, covering everything a checklist designer might need. The full hierarchy is preserved in S/4HANA, including nested parent-child relationships (chapters contain series and tables; tables contain dropdowns; and so on):
Category | Element Types |
Simple inputs | Text input, Number input, Date/time input, Checkbox, Dropdown (+ Option) |
Media & signatures | Signature, Attachment, Attachment picker |
Layout & safety | Label, Page break, Chapter, Safety label |
Complex structures | Table (with header group, column header, column element group, footer group), Series |
Advanced | Calculation, Object picker, Element status |
7. The CDS View Layer
All stored checklist data is exposed through CDS Interface Views that form the consumption layer for analytics and downstream integrations. All views are in package CRMS4_FSM_CHECKLIST_INT on ER1. Extension views expose the extensibility business contexts for customer-added fields.
Template Views
View | Type | Content |
I_SRVCCHKLSTTMPLELEMENT | Basic | All template elements with full field set |
I_SRVCCHKLSTTMPLELMNTTEXT | Basic | Element text in each language |
I_SRVCCHKLSTTMPLDROPDOWNOPTION | Composite | Dropdown option values |
I_SRVCCHKLSTTMPLTABLEELEMENT | Composite | Table element structure |
I_SRVCCHKLSTTMPLSUBELEMENT | Composite | Hierarchical parent-child subelement relationships |
I_SRVCCHKLSTTMPLSTATUS / …STATUSTEXT | Basic | Template status value lists |
I_SRVCCHKLSTTMPLELMNTTYPE / …TYPETEXT | Basic | Element type value lists |
I_SRVCCHKLSTTMPLCATEGORY | Basic | Template category data |
Instance Views
View | Type | Content |
I_SRVCCHKLSTINSTCEVALUE | Basic | Technician-entered element values |
I_SRVCCHKLSTINSTCETEXT | Basic | Instance descriptions per language |
I_SRVCCHKLSTINSTCEDETAIL | Composite | Instance detail (composite) |
I_SRVCCHKLSTINSTCESTATUS / …STATUSTEXT | Basic | Instance status value lists |
I_SRVCCHKLSTINSTCEDELTNREASON / …REASONT | Basic | Deletion reason value lists |
8. OData APIs and Processing Classes
Two OData V4 APIs in package CRMS4_FSM_CHECKLIST_INT receive inbound data from FSA. Both are backed by behavior implementation class CL_CRMS4_FSM_CHKLST_BEHA_IMPL, which routes to separate processor chains:
Inbound — FSA to S/4HANA
API | Handles | Processing chain |
API_SERVICECHECKLISTTEMPLATE | Template data from FSA | CL_CRMS4_FSM_TMPL_PROCESSOR → CL_CRMS4_FSM_CHKLST_UTILITY → CL_CRMS4_FSM_TMPL_XML_PARSER → CL_CRMS4_FSM_TMPL_DB |
API_SERVICECHECKLISTINSTANCE | Instance data from FSA | CL_CRMS4_FSM_INST_PROCESSOR → CL_CRMS4_FSM_CHKLST_UTILITY → CL_CRMS4_FSM_INST_XML_PARSER → CL_CRMS4_FSM_INST_DB |
Outbound — S/4HANA to FSA
For the prefill direction, CL_CRMS4_FSM_REPL_CHKLST_INST handles the filter and template determination logic. CL_CRMS4_FSM_CHKLSTINS_PREFILL orchestrates the full prefill and replication process. The actual HTTP call to FSA uses OData client proxy model CL_CRMS4_FSM_CHKLST_INST_MODEL (proxy model ID: CRMS4_FSM_CHKLST_INST), and errors are logged in AIF under namespace /FSM, interface IF_PRE_CKL.
FSA API endpoints used: Templates are pushed to /api/data/v4/ChecklistTemplate/ (DTO: ChecklistTemplate.19) and instances to /api/data/v4/ChecklistInstance/ (DTO: ChecklistInstance.17). These paths and DTO versions are held in configuration table CRMC_FSM_CONFIG.
9. Extensibility for Customers
The integration is designed so customers can adapt it without modifying SAP code. Two types of extensibility are available.
Field Extensibility
Four business contexts allow customers to add their own fields to checklist objects via the standard Key User Extensibility tools:
Business Context | Object |
CRMS4_FSM_CHKL_TMPL_HDR | Template header fields |
CRMS4_FSM_CHKL_TMPL_ELM | Template element fields |
CRMS4_FSM_CHKL_INST_HDR | Instance header fields |
CRMS4_FSM_CHKL_INST_ELM | Instance element value fields |
The service header (CRMS4_SERV_H) and service item (CRMS4_SERV_I) business contexts also feed into prefill logic — so customer-added service order fields can be used as prefill sources without any code change.
Logic Extensibility — BAdIs in Enhancement Spot ES_CRMS4_FSM_CHKLST_INTEGRATN
BAdI | When it runs | What it can do |
CRMS4_FSM_CHKLST_TMP_BEFR_SAVE | Before a template is saved to the database | Modify or validate inbound template data |
CRMS4_FSM_CHKLST_TMP_AFTR_SAVE | After a template is saved | Trigger downstream actions or notifications |
CRMS4_FSM_CHKLST_INS_BEFR_SAVE | Before an instance is saved to the database | Modify or validate inbound instance data |
CRMS4_FSM_CHKLST_INS_AFTR_SAVE | After an instance is saved | Trigger downstream actions or notifications |
CRMS4_FSM_CHKLST_TMP_DETERMIN | During service order release, before prefill | Determine which checklist template to use per service item — mandatory for prefill |
CRMS4_FSM_CHKLST_TMP_ELMVAL_DT | After standard prefill from mapping table | Override or supplement element values with custom logic |
The two prefill BAdIs matter most for customers. CRMS4_FSM_CHKLST_TMP_DETERMIN is called with the full service header and all line items (including customer-extended fields) and must return which template to use. CRMS4_FSM_CHKLST_TMP_ELMVAL_DT receives the same inputs and returns element values, giving full control over what data the technician sees when they open the checklist in the FSA mobile app.
10. Monitoring
Both inbound and outbound message flows are monitored through the Application Interface Framework (AIF). Operations teams can see individual message status, retry failed messages, and view structured error logs — all without developer involvement.
Use the Fiori app Message Monitoring and Error Handling to monitor replication messages, inspect payloads, and restart failed messages.
Access to the Message Monitoring and Error Handling Fiori App requires the business role SAP_BR_CONF_EXPERT_BUS_NET_INT to be assigned to your user in the SAP S/4HANA Cloud system.
AIF Interface | Version | Namespace | Direction | What it covers |
IF_CKL_INS | 1 | /FSM | FSA → S/4HANA | Checklist Instance — inbound from FSA |
IF_CKL_TMP | 1 | /FSM | FSA → S/4HANA | Checklist Template — inbound from FSA |
IF_PRE_CKL | 1 | /FSM | S/4HANA → FSA | Pre-Fill Checklist — outbound prefilled instances to FSA |
Class CL_CRMS4_FSM_CHKLST_AIF_RESTRT implements the AIF restart BAdI (/AIF/RESTART_SYNC_MSG) filtered on namespace /FSM and interfaces IF_CKL_TMP / IF_CKL_INS. This means failed inbound checklist messages can be reprocessed directly from the AIF monitoring transaction — no manual data correction or developer action required.
11. Authorization
A single PFCG role, SAP_S4C_SERV_FSM_CHKLST, covers the checklist integration. The authorization object CRMS4_FSMC (class: FSM) controls access with two fields:
Field | Value | Meaning |
CHKLST_OBJ | T | Templates |
CHKLST_OBJ | I | Instances |
ACTVT | Read / Change / Delete | Fine-grained activity control per object type |
Read-only access to replicated checklist data can be granted independently of write permissions needed for configuring the prefill feature. This allows analytics users to query instance values without being able to modify integration configuration.
12. Summary — What This Means for the Business
Before this integration, checklist data from FSA was a black box to S/4HANA. Field technicians filled in forms that back-office teams could never see, and back-office teams had no way to give technicians structured starting information for a job.
Who benefits | What changes |
Analytics teams | Completed checklist instance data is queryable directly in S/4HANA — join it with service order data, equipment history, or contract information to build KPI reports and identify quality trends across the field service operation. |
Service planners | Configure templates and field mappings so that every released service order automatically pushes a relevant, pre-populated checklist to the assigned technician — reducing data entry errors and ensuring completeness. |
Developers & consultants | Clean BAdI extension points and field extensibility for any customisation, without touching SAP code. All objects are in a single package (CRMS4_FSM_CHECKLIST_INT) on ER1. |
Operations teams | AIF-based monitoring with restart capability — a failed message is a manageable event. |
Multi-subsidiary organisations | Single-company and multi-company scenarios are both supported. Each FSA company can receive checklist instances independently, driven by the organisational data of the originating service order. |
Source link
