Field Force Management Integration Interface Requirements Version 1.0

Committee Note 01

05 October 2012

Specification URIs

This version: (Authoritative)

Previous version:

Latest version: (Authoritative)

Technical Committee:

OASIS Field Force Management (FFM) TC


Thinh Nguyenphu (, Nokia Siemens Networks


Thinh Nguyenphu (, Nokia Siemens Networks


This document describes the Field Force Management Integration Interface (FFMII) business drivers, business use cases, and high level features requirements.


This document was last revised or approved by the OASIS Field Force Management (FFM) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this document to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at

Citation format:

When referencing this document the following citation format should be used:


Field Force Management Integration Interface Requirements Version 1.0. 05 October 2012. OASIS Committee Note 01.


Copyright © OASIS Open 2012.  All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.




Table of Contents

1       Scope. 6

2       References. 7

2.1 Normative References. 7

2.2 Informative References. 7

3       Definitions and Conventions. 8

3.1 Conventions. 8

3.2 Definitions. 8

3.3 Abbreviations. 9

4       FFMII Business Drivers. 10

4.1 Why field force management implementation projects last so long. 10

4.2 Business architect’s view into field force management. 10

4.3 Desired characteristics of Field-Force Management Integration Interface (FFMII). 12

4.3.1 Applicability across domains and use cases. 12

4.3.2 Technical scalability. 12

4.3.3 Feature scalability. 12

4.3.4 Expression accuracy and user guidance. 13

4.3.5 Reliable message exchange. 13

4.3.6 Deployment adaptability and technology neutrality. 14

5       FFMII Business Use Cases. 15

5.1 Use Case 1: Waste management. 15

5.2 Use Case 2: On-site machinery maintenance. 15

5.3 Use Case 3: Telecom installation. 16

5.4 Use Case 4: Field Resource Availability Survey. 16

5.5 Use Case 5: Power-Line Maintenance. 17

5.6 Use Case 6: Intervention by On-Site Field Force Team Leaders. 18

5.7 Use Case 7: Unplanned absence. 18

5.8 Use Case 8: Cable Service. 18

5.9 Use Case 9: Installed base services for heavy machinery. 19

6       FFMII Features. 21

6.1 Common Design Principles. 21

6.1.1 Separation of Interface Definition and Protocol Bindings. 21

6.1.2 Data-centric interface. 21

6.1.3 Dynamically specified data content and structure. 21

6.1.4 Field communication technology agnostic interface. 22

6.1.5 Bulk operations. 22

6.1.6 Multi-tenancy. 22

6.2 Work Request Management. 23

6.2.1 Work Request data exchange. 23

6.2.2 Work Request Modeling. 25

6.2.3 Work Request Instance Data. 29

6.2.4 Work Request Status. 30

6.3 Reference Data Management. 31

6.3.1 Custom Data Repositories. 31

6.4 System Management. 32

6.4.1 System identification. 32

6.4.2 Capabilities retrieval 33

6.4.3 Assignee Profile. 33

6.4.4 Absence notification. 33

6.5 Integration support features. 33

6.5.1 Authentication and Authorization. 33

6.6 Connectivity. 34

6.6.1 Data integrity and confidentiality. 34

6.6.2 HTTP/HTTPS as de-facto transport protocols. 34

6.6.3 Ability to bypass transport-level security in justified cases. 34

Appendix A.    Acknowledgments. 35

Appendix B.     Revision History. 36




1        Scope

This document describes the Field Force Management Integration Interface (FFMII) business drivers, business use cases, and high level features requirements.

2        References

2.1 Normative References

[RFC2119]           S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997.

[FFMII-SPEC]     Field Force Management Integration Interface Specification Version 1.0. 05 October 2012. OASIS Committee Specification 01.

2.2 Informative References




3        Definitions and Conventions

3.1 Conventions

This specification uses normative text. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119]:

…they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)…

These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

All sections and appendixes, except “Scope” and “Introduction”, are normative, unless they are explicitly indicated to be informative.

3.2 Definitions








Field Force






Field Work












Work Request





3.3 Abbreviations



Business Driver


Business Requirement








Use Case


4        FFMII Business Drivers

4.1 Why field force management implementation projects last so long

Integration of Field Force Management systems into the surrounding IT environment tends to be a costly and time consuming undertaking, although conveying dialog with field force through digital media may appear straightforward on the surface. A fundamental reason is complexity caused by variation among work request types, interaction styles, and sheer number of exceptional cases that need to be handled coherently.

Need for communication with field force is typically not a standalone concern, but rather it is implied by the nature of business processes of a particular company or unit. The role of Field force communication systems is to assist those processes, and therefore they are expected to closely adapt to constraints of each business. Such systems not only serve the field personnel in terms of terminals and user interface, but above all act as an “extended arm” of work planning systems when reaching out for the addressable field force. The versatility of supported interaction paradigms and flexibility of conveyable content can be a decisive factor for success or failure of field force management solutions and related integration projects.

Traditionally, Field Force Management systems have been approached by their designers from two distinct starting points:

While each of these approaches are fully justified in their own right, the major issue is to draw a border-line between what is inside and what is outside the scope of each type of system.

In fast rolling projects, border-lines between functional domains of systems are often crossed (based on seemingly good intentions), with the consequence of solution components no longer remaining focused on a particular area of excellence, but rather trying to address a large set of concerns at once, with various degree of success.  The outcome is often conceptually insufficient or difficult to comprehend and strongly specific to a particular project, therefore also hard to evolve or apply in other contexts.  This creates severe challenges both for businesses seeking out-of-box solutions and for software vendors that spend time developing case-specific solutions instead of focusing on value-add content.

4.2 Business architect’s view into field force management

Ability to construct an IT environment using out-of-box interoperable components is instrumental for cutting project delivery times and integration costs.  In order to achieve this, each individual building block must honor its defined scope; support at least a minimal set of expected features and interaction patterns, while allowing a space for vendors’ own growth within their respective business domains.

Field-Force Management Technical Committee (FFM TC) concerns itself with positioning and interoperability aspects related to ERMS and FFMS.

ERMS and FFMS systems must inter-operate as a part of a larger entity.  While both ERMS and FFMS may individually be integrated with other types of external data sources, their roles create a clear sense of hierarchy.  Figure 1 outlines relative positioning of ERMS and FFMS as promoted by FFM TC:

Figure 1: Field Force Management Integration Interface

The main normative deliverable of FFM TC, the Field Force Management Integration Interface (FFMII) provides a flexible interface between ERMS and FFMS for the purpose of work request modeling, exchange, and collection of data from the field.

FFMII aims to enable an ecosystem of interoperable software solutions that allows the investing party (such as field service provider) to construct an IT environment out of well-defined components fitting a particular purpose, and seamlessly interacting with each other.

From the software vendor point of view, FFMII provides a solid foundation of field work modeling and request exchange. This translates into reduced time to market and an ability to devote more time into market creation and product development activities.

4.3 Desired characteristics of Field-Force Management Integration Interface (FFMII)

4.3.1 Applicability across domains and use cases

Many business drivers of FFMII are related to minimizing the time needed to develop, integrate, and deploy field work management solutions consisting of systems acting in different roles.

Field work modeling of FFMII SHOULD be flexible enough to support different business use cases.  Especially the structure of data content required to model the field work and the process flow varies not only from one business sector to another but also between individual businesses. Cutting time to delivery requires that the same development effort can cover this variability.

The system topology varies greatly between deployments.  Sometimes there is a single work planning system, in other cases multiple sources of work share the same field-force.  Furthermore, the field force might be divided into several independently managed units.  The interface SHOULD therefore support different system topologies having one or more sources for field work and one or more field force management units.

While the interface should be flexible, excessive flexibility easily leads to increased complexity and time to market.  Therefore it is important to balance flexibility with ease of adoption. Ease of adoption is facilitated through elegant interface design and utilization of commonly used and well-supported underlying technologies, such as XML, HTTP, and web services.  It is also important that the interface enables fast prototyping, e.g. to support early phases of project realization and to enable creation of prototypes for pre-sales and other purposes.

4.3.2 Technical scalability

A large scale field work management deployment may involve thousands of field workers. Correspondingly high volumes of data are transferred between the work planning systems and the field communication system.  However, while a high amount of work requests may be deployed in the field (made visible to field personnel); only a fraction of those is typically under active realization at any given point of time.

The interface SHOULD therefore support efficient communication between systems to allow for large scale deployments.  The ability to identify updated work requests is particularly important when synchronizing work request status information.

FFMII SHOULD have the ability to efficiently address groups of data objects to ensure technical scalability of remote communication between interacting systems. Such communication is, by nature, subject to transaction rate, round-trip, and potentially bandwidth limitations.

4.3.3 Feature scalability

While the interface SHOULD be flexible enough to address demanding use cases and interaction styles, all its features are not necessarily required in all deployment contexts.  In order to avoid risks and costs of unjustified complexity, the interface SHOULD enable specialized solutions that implement or use only a sufficient subset of the interface features to implement an end-2-end use case [Note 1].  This, in-turn, opens business opportunities for software vendors specializing on particular markets where the advanced features of FFMII interface would not be of relevance.

Note 1: For example, an ability to exchange work requests based on mutually agreed fixed structure eliminates the need for dynamic work structure modeling where it otherwise would not be of relevance.  See Use Case 4.

4.3.4 Expression accuracy and user guidance

Field operations performance is in proportional relation to the expression accuracy integration interface provides to the work planning system.  Particularly, a precise balance is to be established in order to prevent delays and mistakes caused either by missing information or information overload.

The type of Field Work may range from fairly simple actions to relatively complex sequences of steps. Therefore, FFMII MUST have the ability to convey information that guides the Assignee through individual phases of Field Work.  Additionally, whenever information is to be collected from the field, the work planning system SHOULD have sufficient means to enforce relevant constraints on individual data elements.

Furthermore, any information provided must be clear and understandable, and offered to the Assignee in an intuitive, easy-to-access way.  While it is not the intention of the FFMII interface to deal with low-level data presentation details (e.g. colors, font sizes or item placement), support for a limited set of information visualization assertions SHOULD be available.  [Note 2]

Note 2: For example, to indicate that certain data element is phone number, web-link, or text to be displayed as mono-space element

4.3.5 Reliable message exchange

Successful field operations require that correct data is delivered to and from the field and that any updates are processed correctly.  While correctness of data is always subject to correct operation of involved systems and their users, FFMII MUST provide reliable data communications without risk of data loss.

Modern transport protocols already provide necessary services for ensuring reliable data delivery, such as message integrity verification, sequencing, and resending.  However, additional means of protection are required on application level for ensuring reliable communication even when issues such as data update collisions or loss of synchronization appear.

Data related to field work may be updated simultaneously from the work planning system and by the Assignee.  Such simultaneous updates may be conflicting.  For example, an Assignee might report the work as completed simultaneously with work description being updated in the work planning system.  To detect and correctly handle update conflicts, the interface MUST have means for conflict indication.

Furthermore, under certain circumstances, such as during initialization of a system, it SHOULD be possible to ensure that data between ERMS and FFMS is synchronized.  For such purposes, features enabling efficient data realignment are desirable.

4.3.6 Deployment adaptability and technology neutrality

The deployment configurations may vary significantly. Software vendors’ mode of operation causes further variation.  Some software components of the field force management solution may be provided as a service (i.e. in SaaS mode) over Internet or it may be that all components are deployed to the same host platform.

To support deployment configurations with components communicating over un-trusted networks, such as the Internet, elementary security features such as message integrity and message authenticity capabilities are needed.  Commonly used transport level security mechanisms SHOULD be supported where available.

On the other hand, for deployments where all components are deployed within the same trusted environment, extensive security measures may unnecessarily slow down implementation and cause extra work.  Therefore the interface SHOULD be flexible for each deployment.

All in all, the interface design SHOULD make minimal assumptions regarding the deployment environment.

The interface also MUST NOT imply usage of particular implementation technologies on ERMS or FFMS side, including topics such as choice of operating systems or programming languages.

5        FFMII Business Use Cases

This section contains examples of potential business use cases for the FFMII interface.  The use cases are intended for deriving general requirements for the interface and to verify that the interface design is sufficiently generic to cover different business sectors involving field work and field communication.  The interface itself will not be limited to the use cases described herein, but rather be applicable for many business sectors having similar requirements.

DISCLAIMER: Company or other names used in this document are intended for illustrational purposes only, and have no relation to any real entities whether businesses or individuals.

5.1 Use Case 1: Waste management

Communal Services Corporation provides waste collection services for residents.  In the case of residents living outside of main urban areas, organizing regular collection is not cost efficient.  Instead, the company offers Internet based on-demand type of service for ordering waste collection when needed.

When a new Work Request is created, it contains information such as customer details for invoicing purposes, location of the work place (including more details if needed), and naturally indication of the work type.  The person delivering the service (an Assignee) is expected to submit a simple confirmation to the dispatching center using his mobile device when the Work Request has been completed.

5.2 Use Case 2: On-site machinery maintenance

Service Company Ltd. specializes on expert services for particular machinery used in furniture manufacturing.  Their staff regularly visits customer premises to perform standard assessments as well as serving urgent faults as they arise.  While the visits are regular in nature, it is not always the same Assignee to handle all visits, but rather a person who is on duty and not occupied by other tasks at given moment.  Service Company Ltd utilizes a specialized work scheduling system for making resourcing decisions per each Task instance, integrated with field communication system for delivering Work Requests to field technicians.

In handling site assignments, the Assignee is provided with Work Request consisting of job description, work type, classification of the issues, priority, bill of materials, specialty tools, and expected resolution.  Additionally, history information about most recent calls to the site is included, providing even more of relevant background to the technician.  Due to SLA requirements, it is essential that fault correction jobs are followed up from start to completion. In order to ensure high accuracy of the work performed, detailed technical drawings of machinery are available for the field technicians as well.

When on job, the Assignee is expected to keep the Work Request change log up to date by means of additional text inputs, especially if the issue in question cannot be solved immediately, and the work needs to be interrupted. Should part of the machinery need to be replaced, Assignee is expected to precisely identify both, the part being removed as well as its replacement. This information is particularly relevant from equipment lifecycle management point of view. 

As part of Work Request closing, Assignee is expected to supply a “resolution code” providing indication of the issue and its resolution, of which some codes are more commonly needed than others.  The Assignee also has an opportunity to supply additional information as a free-form text note.

Depending on maintenance service level agreement, the end user may be required to accept delivery using digitally captured signature or request-specific confirmation code supplied through Assignee’s terminal (e.g. mobile phone or PDA device).

5.3 Use Case 3: Telecom installation

Field Connect Company provides telecom installation services on behalf of operators in the region.  Majority of the ordered works deal with the land-line network, and generally involve visiting several distribution points, cross-connect places and end-user premises, depending on the work order content.

A specific Field Work may be dispatched to a single or several Assignees.  Each Work Request contains all details necessary for performing the entire installation, even if possibly some parts of it may be handled by another colleague.  An Assignee typically needs to visit several distinct locations (e.g. cross-connect locations) to perform the work.  He or she may have to switch between locations to create or troubleshoot the required connections.

Whenever multiple Assignees are involved, names of the involved colleagues are indicated in the Work Request, and Work Request status updates will be synchronized to keep each Assignee up-to-date regarding progress the other colleagues have made.  The frequency of the updates depends on the work type.

In order to avoid unnecessary delays, a Work Request contains additional location access information for each location, if such is known to the upper-level system.  Such information may include, for example, indication of the nearest suitable parking place, contact for building maintenance companies, detailed navigation information, and alike.  Should the location information prove to be incorrect, incomplete, or missing, Assignee has an opportunity to correct it directly on his device.  Updated location information is propagated to the upper-level system, and cross-distributed with future field request for the same location.

5.4 Use Case 4: Field Resource Availability Survey

Field Force Corporation occasionally has more Field Work to handle than what its Field Force is able to accomplish within standard working hours.  Therefore, during rush periods the company conducts a survey among their field personnel to find out who would be willing and able to work overtime so that they can be assigned extra tasks.

As the company operates in a country with several official languages, plus they also employ some foreigners speaking English language only, the survey is produced by the work planning system using several language variations, of which one is displayed to each person depending on his or her personal preferences set in a user profile.  Nevertheless, the answers are always based on same set of predefined choices (e.g. Yes/No/Can’t Say) so that the collected responses can still be automatically processed and summarized in a uniform way for the work planners.  [Note 3]

Because the survey is conducted outside of normal business hours, and the content is rather simple, the field-communication system chooses to use SMS as an alternative communication channel to reach as large portion of the company Field Force as possible.  The choice of communication channel, however, is transparent for the work planning system.

Note 3: The ability to use multi-language content is not limited to this particular use case but is applicable throughout all use cases where multi-lingual work force may be involved.

5.5 Use Case 5: Power-Line Maintenance

ElectricCo provides electricity transmission and distribution in its region. As such, it is responsible for many assets. Some of these are "linear assets", that is assets that stretch over some path, such as power cables and the above-ground pylons or underground pipes that support them. Other assets are grouped in specific locations such as stations and substations.

As in UC2 and UC3, Work Requests MAY have a complex structure composed of Tasks, Activities and Steps. Additionally, due to the remote location of some assets, there is a need to download some documentation and other info in advance.

For safety and regulatory reasons, work progress needs to be recorded and shared by means of timestamps, step transitions and user input. The same reasons also necessitate explicit statement of dependencies involving complete Tasks and/or specific Steps within Tasks, so that FFMS can enforce conformance with these dependencies. Such ordering and sequencing of Activities, Tasks and Steps are critical, and non-compliance with them may have severe consequences.

While Assignees are at the site, they may have a reason to handle another asset that was not included on the original work request. Here are two possible reasons:

  1. The Assignee notices some problem in an asset near the asset related to the work request and decides to open a new Work Request related to that other asset. Once created, the Assignee may ask that the new Work Request to be scheduled to him or her for immediate execution, or leave it to the scheduling system to schedule the work request to some other time and/or Assignee.
  2. The Assignee may ask the scheduling system to look for existing Work Requests that are currently unscheduled or scheduled for a later date and that relate to other assets in the same area. Once such Work Requests are found, the scheduling system may automatically schedule them to the Assignee, or display such work requests to the assignee and allow him or her to choose one that best fits the current situation (e.g. remaining time, accessibility, available tools).

The above workflows imply a more general paradigm of Field-Initiated Interaction, where FFM is the origin of new Work Requests, Tasks, Activities etc., or changes in such items that already exist.

5.6 Use Case 6: Intervention by On-Site Field Force Team Leaders

ElectricCo divides its Assignees into teams that regularly co-operate in the field. While ElectricCo may have sophisticated automated scheduling and/or human operators (dispatchers) managing Assignee schedules, final responsibility for getting the tasks done reliably and safely rests with team leaders in the field. For that reason, team leaders occasionally need to be able to query the Work Requests and current status for members of their teams.

In some cases, team leaders also need a way to request specific interventions to the Work Requests. These include releasing an Assignee team member from a specific Work Request; changing the assigned team member for a specified Work Request; and changing estimated times (e.g. start time or duration) for specified Work Requests. These are requests which the ERMS may or may not decide to approve.

5.7 Use Case 7: Unplanned absence

ERMS makes its scheduling decisions based on information regarding which Assignees are available at what time periods or intervals. Occasionally Assignees are forced to deviate from this commitment – e.g. an Assignee who calls in sick, or an Assignee who is asked to perform some other task, outside the scope and knowledge of ERMS. The Assignee needs a way to report the absence (or other reason for not being able to perform the task) to ERMS, so that ERMS can modify the planned schedule accordingly. This is an active notification of absence, which is preferable to passive detection of absence (that is, ERMS deducing non-availability due to the fact that the Assignee does not respond to messages and Work Requests sent to him; though a typical ERMS implementation will probably support such passive detection of absence as well).

As in UC6, team leaders should also be able to report unplanned absences on behalf of their teams.

5.8 Use Case 8: Cable Service

CableCo provides cable TV, Internet and wired telephony to customer homes. During a service visit, Assignees may need to activate a new set-top box (STB). For that, they read the STB's number (and/or number of card inserted into the STB) – such numbers may be obtained via RFID, barcode or other automated means. This number should be recorded and send via FFMII to ERMS.  ERMS may then need to provision the new STB:  ask for activation, and receive indication for activation status. Such requests from the field are routed through ERMS to the request's designated target.  FFMS expects a response to this request that it has initiated and created.

Note: It is imperative for such requests to be routed through ERMS in order for it to perform book-keeping of the out-bound messages sent to external systems (e.g. activation of specific cable services), and the responses received. Otherwise the record of the performed service, and its actual status as completed successfully, could not be known to ERMS.

The Assignee may also need to interact with the customer regarding non-technical issues, such as viewing and explaining the latest cable invoice or selling additional services. While such issues are outside the FFMII scope, the Assignee reports the additional interaction with the customer and any additional service performed to the ERMS via FFMII. Furthermore, based on this input, the ERMS adds new Activities and Steps to the Work Request, as necessary, including indication as to whether further payments, signatures, approvals etc. are required so that FFMS can properly guide the Assignee.

5.9 Use Case 9: Installed base services for heavy machinery

Globally operating Heavy Machinery Manufacturing Ltd (HMM) is a design, manufactures and services power production systems used mainly in ships and power plants. A broad range of services is offered, ranging from basic support such as on-request service calls, installation and commissioning, to performance optimization, upgrades, agreements focusing on overall equipment performance, and asset management.

On-call service repair calls are the most important Field Work type (about 80% of service orders) and are performed by 1-2 Assignees. Preventive maintenance (e.g. service, inspection) and troubleshooting assignments are also common. Major overhauls and commissioning require multiple Assignees with a team leader and may have duration of several months.

Field Service Order Coordinators schedule and assign Field Work, collect details, and perform travel arrangements. Usually spare parts are arranged by a separate Spare Parts Coordinator. The customer usually has technical manuals with service instructions, and makes them available.

A work order includes: Order number, Installation number & name, product number, customer number & name, and the task(s) to be completed. Related persons are also specified: Service coordinator, Account manager, Leading Service engineer (if any). Contact details of all HMM persons, customer contact and location details are provided. In addition, packing lists, a Proforma Invoice, delivery claim and cargo documents are made available to the Assignee. Dependencies between activities exist – some tasks must be complete before dependent tasks. Some customer locations lack network connections, and the cost of data roaming in some locations is prohibitive. Therefore off-line availability of work orders is important.

Sometimes an Assignee carries spare parts personally, but normally spare part logistics is managed separately due to physical size of required parts. Usually Field Work at site starts with a step for checking that all required spare parts have arrived. For this purpose, the Assignee has a listing of expected materials that can be compared with packing lists of arrived shipment(s). All spare parts ordered for a work order are assumed to be used. Exceptions may occur and are reported. The customer may keep the extra spare parts or they may be sent back for restocking.

Some Work Orders have a fixed price, but are mostly charged based on used time (preparation, execution, reporting), spares, and travel costs (time + costs + margin). Sometimes (e.g. off-shore operations) time is reported and charged by a detailed activity type. Hourly rates vary by field service person category and market area. Workforce utilization rate is a primary key performance indicator (KPI). To facilitate calculation, all work hours (billed or not, overtime), vacations, and idle time are recorded. Other KPIs are the workforce invoiced utilization rate and time to invoice.

Upon completion of Field Work, customer signature for spent hours is usually required. Additionally, an Assignee creates a free-form work order report that must be accepted by the Field Service Coordinator and subsequently delivered to the customer. Internal comments (not visible to customer) may be created. About 500 work reports are created each week globally. Smaller units of Field Work are reported on completion, and larger cases on weekly basis.

Sometimes an Assignee identifies opportunities for additional sales of services or equipment. These are reported in context of the equipment or site so that the corresponding account manager can contact the customer knowing appropriate details (Sales lead in CRM).

There are about 30 standard technical parameters per engine type that are measured in inspections and overhauls, and recorded in association with the product individual. Measurement of wear of cylinder liners provides an example.

Each product individual has individual compositional structure that is maintained for recording compatible spare parts. Compatible spares may change at product individual level, e.g. an engine is modified to use oversize cylinder liners to compensate for wear. Furthermore, customers or competing service providers may install third party spare parts or modify equipment. In such cases part changes may not be recorded in HMM’s system. It should be possible for an Assignee to report detected changes. Because an engine consists of about 3000 material numbers, it should be possible to pick the corresponding location code from a structured list, and then attach a related note or code.

6        FFMII Features

This section describes the required high level features of the FFMII interface.  These features are derived from the potential FFMII business drivers and business use cases in the above sections.  The “Origin” heading shows a reference of where each of the requirement.  Related features are grouped into sections and subsections.

6.1 Common Design Principles

6.1.1 Separation of Interface Definition and Protocol Bindings

The FFMII interface specification SHALL be split into its transport independent part (the interface concept) and one or more supported protocol bindings.

Rationale:   This distinction is essential as to allow the interface concept to stabilize despite eventual extensions and enhancements on message exchange level.  Additionally, while the transport independent part of the interface specification is provided as a text document, for some protocol bindings the specification MAY be provided as a set of machine-readable artifacts (e.g. data models in XML) rather than text.

Origin:  BR/Future-Proof Design

6.1.2 Data-centric interface

The FFMII interface SHALL be data-centric, that is, providing only a limited set of generic calls while being flexible on data level (payloads).

Rationale:  Data-centric interfaces represent a proven design pattern allowing constructing and verifying message exchange logic, including an option of forwarding proxies, independently of the actual business use cases being served and/or containing variations across work requests.

Origin:  BD/Cutting integration costs, BD/Cutting time to delivery, BR/Adaptability to use cases

6.1.3 Dynamically specified data content and structure

The FFMII interface SHALL support dynamic definition of data elements and structural Work Order definitions.

Rationale:  Different business use cases require different data content and structure.  For example, telecommunication installation work typically has a number of product-specific technical parameters such as cable pairs or IP addresses while on-site maintenance work might have machine-specific instructions or documentation. 

Origin: BR/Expression accuracy, BR/Adaptability to use cases

6.1.4 Field communication technology agnostic interface

The FFMII interface SHALL NOT mandate any particular technology or implementation approach, using which the received Work Requests are communicated to the Field Force.

Rationale:  While the FFMII interface is explicit in work request structure and content, it does not prescribe particular communication technology used for delivering messages to field personnel.  It therefore opens opportunity for various kinds of solutions using technologies, such as Web, on-device clients, SMS, and others, or even combinations thereof upon vendor consideration.  This approach not only off-loads the work planning system of the low-level details of information visualization, but also opens possibilities for competitive offerings each profiling itself in particular way.

Origin: BD/Fit for purpose, BD/Ecosystem enabling, UC4

6.1.5 Bulk operations

Whenever applicable, the interface specification SHALL provide support for bulk operations

Rationale: Operations handling several data objects in a single call are an efficient way of mitigating impact of network latency and round-trip delays inherent to remote communication protocols.

Origin: BR/Technical Scalability

6.1.6 Multi-tenancy

Single Implementation of FFMII interface SHOULD be able to receive Work Requests from one or several distinctly identified Managers simultaneously, yet maintaining an appropriate level of data isolation between those.

Rationale: This capability is a pre-requisite for a single Assignee being able to deliver works requested by different ordering parties without need for dedicated field communication solution towards each ordering party individually.

Origin: BR/Shared Field-Force

6.2 Work Request Management

6.2.1 Work Request data exchange Deliver and update Work Requests in the field

FFMII interface SHALL provide means for dispatching Work Requests and their updates to the associated Assignees.

Rationale: Ability to formulate and dispatch Work Requests is a fundamental feature of field communication interface. Planned Tasks are communicated to field personnel as Work Requests.  When work schedule, instructions or other Field Work related information changes, the associated Work Request must be updated to notify Assignees of the changes.

Origin:  UC-All Receive Work Request status information from the field

The FFMII interface SHALL provide means for retrieving Work Request status information from the field.

Rationale: Ability to follow-up progress of requested Field Work is instrumental from the operational and also business process points of view. For example, a customer may need to be informed when Field Work starts or completes, and progress and timely completion of ordered Field Works may have implications on invoicing and auditing of SLA performance. Work request status reporting may also be important for other reasons not directly related to monetary or contractual aspects, such as work safety requirements.

Origin:  UC-All Receive Work Request data update from the field

FFMIII interface SHALL provide means for retrieving data from the field specifically denoted as expected user input in the Work Request structure.

Rationale: A business process involving Field Work may expect an Assignee to provide information related to a Work Request, for example, indication of the work hours or number of kilometers to be billed from the customer. Such additional information may need to be provided at different stages of the Field Work, depending on the use case, and its semantics may depend on the current status of the Work Request.  Therefore, the containing process must be able to receive additional user provided Work Request data with status information.

Origin:  UC-All Receive Work Request status change notifications from the field

An Implementation SHOULD be able to dispatch notifications towards the Manager concerning Work Requests status of which has changed.

Rationale: When the number of deployed Work Requests is high, it is not efficient to poll status of each of them separately (or even as a bulk operation).

Origin:  BR/Efficient messaging Ability to query Work Requests based on overall status and time of most recent change

FFMII interface SHALL provide means for Manager to query high-level status information of the deployed Work Requests, in order to identify Work Requests that have been changed within given period of time.

Rationale: In the event of losing synchronization between Manager and Implementation, a Manager should have an option to iterate over high-level status information of already deployed Work Requests without retrieving all details of each Work Request.  Based on query result, Manager should be able to retrieve complete detail of one or more Work Requests.

Origin:  BR/Efficient messaging, BR/Realignment Ability to cancel Work Request

FFMII interface SHALL provide means for Manager to cancel Work Requests.

Rationale: A Work Request is sometimes cancelled, for example because the original order is cancelled.  It is also possible that a Work Request or some included activities are withdrawn from a specific Assignee, and assigned to another person.  Therefore, it should be possible to cancel Work Requests.

Origin:  UC3 Ability to initiate Work Requests from the field

FFMII interface SHALL provide means for FFMS to initiate new Work Requests through interaction with ERMS. Optionally, initiating such requests may lead to an "appointment booking" workflow: ERMS responds via FFMII by offering several options for the timing of the new WR. FFMS then allows the person for whom the new WR is requested to select one of the options. FFMS then reports this choice to ERMS.

Rationale: Sometimes the need for a new Work Request is discovered by the Assignee of an existing Work Request. In such a case it shall be possible for the Assignee to use FFMS to initiate creation of a new Work Request.

Origin:  UC6 Search, view, and select Work Requests from the field

FFMII interface SHALL provide means for FFMS to search, view, and select Work Requests matching specific criteria, such as time range, location etc. When ERMS responds with the search results, the Assignee may request that one or more of the returned Work Requests should be assigned to him or her.

Rationale: Sometimes the Assignee has more free time than expected and needs a way to find additional work that needs to be done in the near future and the nearby area.

Origin:  UC6 Request changes in Work Requests across teams

FFMII interface SHALL provide means for the Assignee to request changes in Work Requests, e.g. change the duration of an activity, or replace an Assignee with another Assignee on the same team. The request MUST include the requester's identity, to enable the ERMS implementation to determine whether the requester has the right authorization for such requests.

Rationale: team leaders often work as Assignees in the field, but they still require some level of visibility and control over their team's activities.

Origin:  UC6 Interaction with other systems

FFMII interface SHALL provide means for carrying messages that are initiated in the field and targeted at other systems (not the Manager), and messages flowing in the opposite direction. These messages SHALL include identification of the Assignee who is the originator or recipient in of the message, and identification of the Work Request which is the context for the message. FFMII SHALL enable two ways of sending responses to such messages: Either synchronously, within the body of response to the message; or asynchronously, where the reply to the message includes just a standard acknowledgement and the actual response is sent later. The messages exchanged in this way may be dynamically specified by ERMS.

Rationale: During a service visit, Assignees may need to request some remote actions from the service organization's operational systems and/or other employees. This interaction needs to be placed in the context of the current Field Work.

Origin:  UC8

6.2.2 Work Request Modeling Separation of Work Request structure and instance data

FFMII interface SHALL allow separation of Work Request structural definition from instance data.

Rationale: While both work request structural definition and instance data are both logically part of a Work Request, it SHOULD be possible to separate these two concepts due to following reasons:

Still, the FFMII interface SHALL also support inclusion of complete Work Request structural definition as part of the request itself.

Origin:  BD/Adaptability, UC4, BD/Ecosystem enabling Support for multiple parallel Activities within a Work Request

Work Request SHALL be composed of one or several Activities possibly taking place at different locations.

Rationale: Different business use cases require an Assignee to perform different kinds of distinct Activities to complete a Work Request.  For example, a communal waste collection Task MAY include a single waste collection Activity.  Meanwhile, a telecommunication installation work may involve connection Activities at several different locations and an equipment installation Activity in yet another location.  Therefore, a Work Request must support multiple, possibly parallel, Activities that may need to be performed at different locations.

Origin:  UC1, UC3 Support for dynamically specified workflow on Activity level

FFMII interface SHALL support definition of dynamically specified workflow on Activity level.

ERMS specifies the States and Steps of an Activity as well as the available transitions between the Steps dynamically as part of the structural definition of a Work Request. A different state model can be specified for each Activity, typically depending on the type of the Activity or the containing Work Request. The specified state model also forms the basis for tracking the status of Activities.

Each dynamically specified State is explicitly associated with one of the predefined Status Categories, indicating the overall status of the Activity from Assignee perspective when in the particular State. Status Category does not affect state model execution but may be used by the Implementation for, for example, visualization purposes. Status Categories are described in Section

Rationale: Different business use cases may require different workflows and different levels of status tracking for associated activities.  Some short duration tasks such as waste collection may only require reporting of task completion while tasks of longer duration and specifically tasks with SLA requirements may require reporting both start and completion times.

Furthermore, even in case of standardized Field Work types, workflow alterations on individual work request level might be needed, especially if progress at each step is to be followed by the Manager.  In such case, it SHOULD be possible for a Manager to construct a custom work flow on activity level.

Origin:  BD/Adaptability, UC-All (Note 4), UC5

Note 4:  Each defined UC, indeed, relies on somewhat different workflow (progression of applicable Steps and States). Work Request state constraints

FFMII interface SHALL provide means to assert constraints for state transitions on Activity level, covering issues such as dependencies between and within Steps of Activity level workflows and mandatory user data input.

Rationale: The Field Work process may imply a number of constraints regarding the way a unit of work (or group of related units of work) is delivered by Assignees. Such constraints may result into a need to sequence activities, a need to avoid parallel activities, or specify rules on access to different parts of work request data at different stages.

For example, in some contexts a particular activity may not be started until a related activity reaches its final state.  Similarly, it might be desired that an Assignee explicitly closes or suspends an activity prior to moving onto another task.  Furthermore, updating Work Request content is typically not desired (and should be prevented) after it has reached a closed state.

Origin:  BR/Accuracy of Control, BR/Rich expressive capabilities Ability to declare data element sets for data display and user input

FFMII interface SHALL allow declaring data elements that are intended to be shown to Assignee and that are required as input during Work Request realization using limited set of reusable primitives (declaration clauses).

Rationale: Each Work Request MAY include several data elements (possibly data element sets) that are intended to be shown to the Assignee to convey details of the work to be performed.  Similarly, any information that is to be collected from the field needs to be formalized in the Work Request.

As instructions and user-input data are Work Request specific, FFMII interface SHOULD provide modeling and data binding capabilities allowing such data to be specified with a moderate set of generic, reusable primitives.

Origin:  BR/Adaptability, UC-All Ability to declare most commonly used input values for data elements

FFMII interface SHALL allow declaring most common values for required input data elements.

Rationale: It SHOULD be possible to define preferred or most commonly used input values for a given input field whenever user input is required. This helps avoiding user errors and saves time.

Origin:  BR/Field Operations Efficiency, BR/Error Avoidance, BR/User Experience, UC2 Documents and multi-media attachments

FFMII interface SHALL provide support for inclusion of documents and multi-media attachments as part of Work Request and/or user input.

FFMII SHALL support document attachment metadata. The FFMS implementation and/or the FFMS user may use this information to better manage the document access process at their discretion, e.g. download a large file only when a fast connection is available, or prioritize so that files with high relevance will be downloaded first, or downloaded even if they use link attachment instead of explicit attachment.

Rationale: Some necessary information (e.g. instructions) may not be available as structured data.  It shall be possible to include with a Work Request attachments such as PDF files, vector or raster graphics, and alike.  Attachments may also be valid input provided by an Assignee, such as photographs taken with the mobile equipment or on-site uploaded files.  Since some work is done at remote location where network access is not guaranteed, FFMII shall enable making it mandatory to download some files (by using explicit attachment) and providing "hints" such as file relevance so that the implementation can decide whether to download files that use link attachment.

Origin:  UC2, UC5

6.2.3 Work Request Instance Data Ability to specify schedule for Work Request

FFMII interface SHALL provide means for specifying Work Request delivery schedule information.

Rationale: Work Request tasks typically have a target schedule, possibly involving contractual deadlines and agreed appointment times.  For example, a telecommunication installation may have a contractual deadline and a separate field appointment time window agreed with the customer.  At least the following schedule information may be relevant.

Note 6: As determined by work planning and scheduling system

Origin:  UC1-4 Peer work progress awareness

FFMII interface SHALL offer means to declare and indicate progress of Activities handled by other Assignees (peers) in the context of a single Work Request.

Rationale: Awareness of Peer work progress is instrumental in certain contexts.  For example, in telecom area, an Activity assigned to a single person or service provider may be closely related to Activities assigned to other persons or service providers.  It is therefore essential for an Assignee to be aware of progress of Peers’ related work. Consequently, the FFMII interface shall offer necessary concepts for Peer identity and activity status propagation.

Origin:  UC3 Local Work Request data updates based on input data or user actions

FFMII SHALL provide means to declare operations that enable Work Request instance data updates inside of Implementation as a result of state transitions on activity level without direct involvement of Manager.

Rationale: Support for locally performed data updates is necessary in certain situations where user experience would otherwise be impacted by round-trips between Implementation and Manager. For example, submitting a new comment should update the change log immediately rather than being “post-updated” by manager later on.  Similarly, it might be required that a specific data element is locked (becomes read-only) immediately upon particular state transition initiated by the user.

Origin:  BR/User Experience, UC2

6.2.4 Work Request Status Work Request history recording

FFMII interface SHALL support concept of Work Request history capturing each state transition and user input that occurs during Work Request implementation. Work Request history SHALL be made available for retrieval by Manager without any additional post-processing.

Rationale: Activity is a set of Steps and associated data.  As the Assignee proceeds from one Step to another, each transition needs to be recorded, as well as any submitted input data. It is then up to the Manager to interpret the transition between each Step. Collection of all Activity level history data forms Work Request history, which is the ultimate evidence of how the Assignee has performed the requested unit of work.

Origin:  UC-All Work Request Status Evaluation and Reporting

FFMII Interface SHALL includes a concept of overall Work Request status complementing the detailed Work Request history as discussed in Section

Work Request status SHALL be derived from the current state of underlying Activities using a fixed set of rules and can therefore be consistently evaluated by both Manager and Implementation. The status information SHALL be exposed to Manager for retrieval and filtering purposes. Same information may also be leveraged by Implementation for, for example, visualization purposes.

The overall Work Request status is described using Status Categories. The same Status Categories are also used on Activity level.

The following Status Categories SHALL be used:

NOTE: The overall Work Request status on FFMII level does not necessarily have to be the same as the status value shown to users of the related systems. For example, the Manager MAY maintain much more fine grained status based on the work history.

FFMII specification SHALL also define a set of predefined more detailed Status values, each of which belongs to one Status Category. The detailed Status values MAY be optionally used in the workflow specification to give a more detailed generic classification of a particular Activity State or Work Request closing state.


In some use cases it may be sufficient for the Manager to act solely based on the high level status of the Work Request.  For example, waste collection task may only involve acknowledgement of completion. Furthermore, even if full Work Request history is used for reporting purposes, the high level status may be sufficient to trigger related business process and tasks flows on ERMS level.

Additionally, it is also important to establish a common, consistent understanding between Manager and Implementation about the current overall state of a Work Request and the contained Activities to avoid misunderstandings between parties responsible for work planning and delivery. This requires a set of common predefined high level Status Categories, layered on top of the detailed dynamically specified Activity state model. Predefined vocabulary is also needed to be able to specify fixed set of rules for determining overall Work Request status.

Origin:  UC1, UC4 Work Request update conflict indication

FFMII interface SHALL include means to indicate conflicting updates of Work Request data by Manager and Implementation.

Rationale: Work Request and its status form a shared data element jointly managed by the Implementation (Work Request handling party) through user actions, and Manager (Work Request initiating party).  Both entities may initiate changes to any part of the status data independently of each other. In order to prevent loss of information, means of conflict indication are required for making each entity aware of changes made by the other.

Origin:  BR/Conflict indication

6.3 Reference Data Management

6.3.1 Custom Data Repositories

FFMII interface SHALL provide means for deploying and remote maintenance of custom catalogs on Implementation side containing data entities that Work Requests refer to or may use as source of input data.

Custom Data Repositories feature provides a generic concept of repositories for storing arbitrary data.  Custom Data Repositories are provided through normalized, content agnostic data exchange interfaces.  Deployed data can be referred to as valid work request input values, or as a source of display information (e.g. “user manual for device XYZ”).  The link between Work Request and its reference data is managed autonomously by the Implementation without Manager’s involvement. 

Rationale: More complex Work Requests may rely on a number of common background registries of static data, such as product catalogs, code sets, and large attachments (e.g. user manual library, site drawings). While master databases of such information typically reside outside of the FFMII Implementation, for practical reasons it is beneficial to provide copies of such data for Implementation use.

This approach, denoted as “Reference Data Management”, has the following advantages:

Origin:  UC2 (one of implementation options for “resolution codes”), UC4 (technical drawings of major water distribution points)

6.4 System Management

6.4.1 System identification

FFMII interface SHALL provide means for the Implementation and Manager to identify itself and the version of the interface it supports. The system itself MAY also expose additional information identifying the vendor and product.

Rationale: Exposure of system identity and interface version is a pre-requisite for establishing trusted reliable link between Manager and Implementation.

Furthermore, by indicating the vendor and product information, the system MAY, at its sole discretion, take into use certain mutually known features or extensions that are not part of the FFMII interface specification. 

Origin:  UC-All, BD/Adaptability

6.4.2 Capabilities retrieval

FFMII interface SHALL provide means by which Implementation and Manager are able to indicate in fine-grained level what features of the overall FFMII specification they support, including related properties accompanying such features.

Rationale: All features of the FFMII interface are not necessarily required in all deployment contexts.  A Implementation and Manager shall be able to verify that the features required in a particular context are available by examining capability descriptors exposed by the other system. Capability descriptors also enable an Implementation and Manager to remain formally compliant with the specification without implementing all features of the FFMII interface.

Origin:  BR/Ease of Adoption, BD/Fit for purpose

6.4.3 Assignee Profile

FFMII interface SHALL provide means of retrieving and updating Assignee information on Implementation side to the Manager.

Rationale: Assignee identification data must be defined and synchronized between Manager and Implementation, in order to eliminate risk of technical faults due to Assignee data not being consistently defined on Manager and Implementation side.  Optionally, this may involve additional information about user preferences and device profiles, if managed outside the Implementation.

Origin:  BR/Ease of Adoption, BD/Cutting integration costs

6.4.4 Absence notification

FFMII interface SHALL provide means for FFMS to report an unplanned Assignee absence. The absence notification SHALL include at least date and time of start and end of absence, as well as reasons for the absence. FFMII SHALL enable canceling or modifying such notifications at a later time. FFMII SHALL enable appropriately authorized users to add or change absence notifications on behalf of the absent user.

Rationale: Unplanned absences occur often in any workforce. The sooner that the absence is reported, the easier it becomes to rearrange the schedule accordingly

Origin:  UC7

6.5 Integration support features

6.5.1 Authentication and Authorization

FFMII interface SHALL require Manager to authenticate itself when accessing Implementation, and vice versa.

Rationale: Field Work is a critical part of a business process and involves confidential data, such as customer details.  The Manager and the Implementation must be able to establish mutual trust.  Furthermore, multiple Managers may be using the same Implementation with different levels of authorization.  Therefore, protocol bindings should offer mechanisms for mutual identification and authentication, especially when using un-trusted networks, such as the Internet, for connectivity.

Origin:  BR/Security

6.6 Connectivity

6.6.1 Data integrity and confidentiality

FFMII interface SHALL provide means to ensure integrity and confidentiality of the data exchanged between Manager and Implementation.

Rationale: Work Request MAY contain information that, if modified in a non-authorized way or disclosed, MAY have negative consequences from business or legal compliancy point of view. To be able to use un-trusted networks, such as the Internet, the protocol bindings SHOULD support transports that are able to guarantee data integrity and confidentiality.

Origin:  BR/Security

6.6.2 HTTP/HTTPS as de-facto transport protocols

In order to promote inter-working of software systems over Internet or other types of IP networks, at least one of the protocol bindings must support HTTP/HTTPS protocols as possible transports.

Rationale: HTTP/HTTPS are proven de-facto standards for scalable communication in Internet context

Origin:  BR/Ease of Adoption

6.6.3 Ability to bypass transport-level security in justified cases

FFMII interface SHALL allow bypassing transport-level security when the deployment environment is known to be secured by other means, or the integration does not carry data requiring protection.

Rationale: In case of strongly isolated, protected networks, an additional layer of transport level security is unnecessary, and might need to be disabled in order to preserve computational resources on Manager or Implementation side.

Origin:  BR/Fast Prototyping, BR/Minimal assumptions regarding the deployment environment

Appendix A.           Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:


Israel Beniaminy               ClickSoftware Technologies Ltd.

Jiri Hlusi                                Nokia Siemens Networks GmbH & Co. KG

Johannes Lehtinen          Rossum Oy

Thinh Nguyenphu            Nokia Siemens Networks GmbH & Co. KG

Ilkka Salminen                   Newelo Oy

Jose Siles                             Nokia Siemens Networks GmbH & Co. KG

Juha Tiihonen                    Aalto University Foundation

Sami Vaskuu                      Newelo Oy

Liat Zahavi-Barzily      ClickSoftware Technologies Ltd.


Appendix B.            Revision History




Changes Made


21 July, 2011

Thinh Nguyenphu

Initial draft based on --- FFMIIBusinessUseCasesFeatures20110628-D.docx

Use case 5,6, and 7 of FFMIIBusinessUseCasesFeatures20110627-D - IB comments, 6-Jul-11.docx


25 July, 2011

Thinh Nguyenphu

Resolved comments in section 6.4.3


18 August, 2011

Thinh Nguyenphu

Based on FFMII-BusinessUseCasesFeaturesREQ-v1.0-wd01-07252011 following discussion of 16-Aug-11.docx


22 August, 2011

Thinh Nguyenphu

Input from


05 September, 2011

Thinh Nguyenphu

Editorial clean up based on September 05, 2011 conference call


09 September, 2011

Thinh Nguyenphu

Editorial clean up and updated Appendix A


12 September 2011

Thinh Nguyenphu

Editorial and technical clean up in all sections


19 January 2012

Thinh Nguyenphu

HeavyMachineryServiceUseCase 02-online-edited


28 February 2012

Thinh Nguyenphu

Editorial clean up Section 3.2 and 3.3


29 February 2012

Thinh Nguyenphu

Fix [FFMII-SPEC] reference