Enabling Field Maintenance Workers with Box and Zia Consulting
This blog post was written by Tony Melrose, a Platform Solutions Engineer at Box
Last month, a few members from the Box team headed to Boulder, CO to partner up with Zia Consulting for a two-day hackathon focused on building cloud content management solutions for a fictional company. The group split into teams and focused on a common problem for many businesses: a field maintenance worker’s workflow. These workers often work solely from mobile devices, assessing broken parts with minimal access to computing resources.
Leveraging the Box Platform APIs, webhooks and a few non-Box services (I’ll get into these later), we built a mobile application that ingests a photo, leverages OCR capabilities to identify a part’s serial number, does a database lookup for the product information based on that serial number, applies metadata to the image file in Box and kicks off a workflow for part replacement based on that metadata. While the Box Platform alone can’t solve for this entire workflow, Zia’s expertise in enterprise content management workflows helped us tie into other services to drive to a viable solution.
The Process
Each team approached the problem slightly differently, and I’m going to share with you the approach that my team took by building out a small Flask application in Python that could link into each of these other services or provide the necessary metadata values required to start relevant workflows.
First, we determined the flow of information through the application and pulled together a rough architecture diagram to inform our decisions around building the application.
This image represents the flow of data, starting on the left-hand side with the Rocket Field Engineer who takes a photo of a part that’s in need of maintenance.
We created an application through the Box Developer Console for this process with a key that we would share across all flows in the app. Each Rocket Field Engineer (RFE) would need to log into the mobile application but didn’t need access to the Box interface, making them perfect candidates for our App User model. We would have centrally-owned content using a Service Account and each RFE would be creating a folder within that central repository with a folder name of “Work Order Number ####”.
We configured a webhook to watch for FILE.UPLOADED events on the centrally managed folder, which cascades to any subfolders, enabling us to see when a new image is uploaded to a newly-created work order and send that over to Ephesoft for scanning. Ephesoft offers a whole portfolio of intelligent capture and scanning solutions. Now that we have the backbone in place, let’s look at the actual meat of the application.
The RFE takes a photo of a part that they feel is in need of maintenance using a custom mobile application (which could be built using one of Box’s mobile SDKs). This creates a new work order folder and uploads the file into it. It also triggers a webhook to our application so we have the file ID of the newly uploaded photo that we can use to initiate a download request.
Once we have the file, we can send it over to Ephesoft for character recognition and database lookup using Ephesoft Transact. After the file has been processed, we receive an XML response from Ephesoft that includes information such as the serial number, product name, product cost, etc. that Ephesoft was able to identify in the image.
For expediency in our hackathon application, we just wrote the response to a file and then parsed that, converting it to a JSON object to pass into the Box Metadata API request.
The JSON object was then transformed to map to the fields we used in our metadata template so we could place our call back to Box with the appropriate metadata based on everything we now know about the image.
Once the metadata was applied to the file, a Nintex workflow was kicked off to either create a purchase order automatically or route the request for approval by a manager if the product cost exceeded a certain dollar value. Nintex is an intelligent process automation tool for creating cloud-based workflows. This is a simplified interpretation of what it could look like in the real world but essentially Nintex provided us with the ability to create logic in the workflow and route the same workflow to different people based on a certain metadata value.
Once approved, the Rocket Field Engineer could expect to receive the replacement part to complete the maintenance — all without having to fill out any forms or manually look up serial numbers — thereby improving their capacity and essentially eliminating human error with incorrectly entering information into a text field.
This entire process leverages a few key technologies to solve for an end-to-end solution. First, we leveraged the Box Platform APIs and webhooks to integrate Box into a mobile application to capture images and send a webhook event upon upload. Then, we built an integration with Ephesoft to analyze and extract information off the image file and write the results to Box’s metadata APIs. In the near future, we’ll be able to leverage the Box Skills Kit for this, which provides easy-to-use access tokens for reading the file and writing metadata to Box. Then, we leveraged Nintex to trigger a workflow when certain metadata values were applied.
