Facility Source (FS) provides facility maintenance optimization to its Clients nationwide. We use fmPilot 1.0 & fmPilot 2.0 as a proprietary software to facilitate every aspect of our service.
Both the systems offer our Clients a one stop solution for work order Management and Asset Tracking. These systems are used by our Associates, Clients and Service Provider (SP's).
Each user has permission based access, so they have access to functions and visibility within the fmPilot systems based on their requirement.
fmPilot has two parts: 1.0 and 2.0, and usage of these depends on the SP chosen to complete the work.
fmPilot: This system is used by our Clients to create and manage work order (WO).
fsElite: This app is used to track the SP and their activities on the assigned WO.
There are several systems (mostly invisible to the end user e.g. client or SP) which exchange data with each other during the work flow of a WO for various purposes. For an example, markup and taxations process; the IFM Bridge; validation of invoice and quotes for pricing engine and Work Order queue (this is an external application). Internal APIs are the ones that enable the transmission of data between systems of this type. The Internal APIs collect some data and make it available to a certain processing engine(s) and collect the output finally storing it in the database. Further this output can be used by other types of APIs for other related purposes.
The first required operation is pulling of existing WO to retrieve assigned work orders and update the existing work orders. This is an on-demand service that will respond to requests for data rather than an active push of new data, which would require SP's to construct their own services for reception. There are finite limits on the numbers of work orders that may be retrieved in a single pull to prevent any resource “hogging” by large queries.
SP frequently have a need to modify the status of a WO, and often the status has been modified within a SP’s core systems and that data simply needs to be transmitted. This may be a fulfillment of a WO, acceptance of a WO, or suspense of a WO that is awaiting materials.
Each of these statuses has its own business logic within the application itself, so this will need to be mirrored within the service to ensure that all notifications, validations and processes are followed correctly. Additionally, all status updates undergo a general validation rule prior to transition-specific validations.
As WO evolve, technicians need to apply notes either for client usage, notes to continuing technicians, and other pertinent administrative information. A service is implemented that receives and annotates these comments relative to a particular WO. Pulling for comments are also implemented.