Field service projects, and their associated work assignments, often require coordination of multiple field service representatives (employees, independent contractors, gig-workers, etc.) performing related and associative tasks in parallel. The data collected and/or created in support of performing and executing workflows often occurs while the field service representative is working offline from the company’s project management system and databases. Offline operation is required necessary given poor connectivity in many field service locations and often requires the storage of large datasets on the field service device. Enabling the workforce to perform work in parallel is key to minimizing the amount of time, cost, materials, and resources required to complete a project. But this “concurrency of work” with its related transaction processing and data collection may create issues in correctness in the data representing the measurements, status, and resources associated with the project. The project management system, the workflow engine, and the workflow design must support and take into account concurrency of activities and maintaining accuracy in the information associated with the measurements, status and resources of the project.
Critical vs. Non-Critical Operations
Workflows can be broken up into sections of “critical or dependent” operations and “non-critical or independent” operations. Critical operations may share data objects and/or resources with other parts of the workflow, have dependencies on other operations before they can complete, and/or affect other operations in the workflow. Non-critical operations in the workflow imply they can be performed at any time, independent of other actions in the workflow. To avoid a “race condition” (https://en.wikipedia.org/wiki/Race_condition) and maintain correctness in the data objects and workflow operations, a property of concurrency control called “mutual exclusion” must be used. Mutual exclusion ensures that if a section of the workflow is already performing an operation on an object (e.g., critical section) no other section of the workflow is allowed to access or modify the same object until the first operation has finished and released the object for other operations to occur. The requirement of mutual exclusion was first identified and solved by Edsger W. Dijkstra in 1965 “Solution of a problem in concurrent programming control”, Communications of the ACM, Vol. 8, No. 9.
Enabling the ability to execute a workflow offline from the main project management or database system and using multiple field service representatives working independently and in parallel on critical sections of the workflow, makes the workflow design challenging and places special functional requirements on the workflow engine.
- This is especially true if you also wish to minimize the time to completion (e.g., optimize efficiencies) of the project. Serializing all tasks in a workflow is the simplest way to guarantee correctness of operation, but this may minimize the use of available resources and maximize the time to completion.
- Another approach is to identify all critical or dependent data objects and resources in a workflow and include “triggers and checks” that make sure all dependencies or “rights of use” are met before the object is accessed or modified.
Even with a well-designed workflow, certain best practices must be followed to avoid common issues of a stalled workflow (e.g., deadlock, livelock, starvation, failure in the absence of contention), reliable operation (e.g., the system crashes or the workflow is interrupted in a critical section), and dependency management (e.g., time between syncing of offline workflow processing devices).
- Firstly, all workflow designs should be subject to a detailed design review by all stakeholders, and made to adhere to a documented set of best practices in workflow design.
- Other examples include fine-grain locking of critical sections/objects of a workflow should be used to guarantee data coherency in the workflow. The data collection devices (e.g., smart phones, tablets, laptops, etc.) should be connected to the project management system and/or synced with the main database system as often as possible. The project management system should notify the associated project manager and field service representatives anytime an assigned and active workflow has not been synced for a pre-subscribed amount of time. A workflow must be released from a field service representative before it is reassigned, avoiding unauthorized data updates.
There are key functional requirements in the project management system, workflow engine, field service device interface, and database system to enable concurrency of operations in a workflow and ensure correctness in the data collected/created. Enabling concurrency in a workflow can be key to maximizing efficiencies in the delivery of field services.