WorkEngine Triggers are one of the most powerful aspects to our Work Management Platform. In this article, I explore the motivation behind them, how we architected them, and how our customers can use them as part of their Robotic Process Automation (RPA) strategy.

Over the years, we’ve watched our customers demand more from their Work Management technology solutions. Whatever their industry— Field Service, FM, Logistics, Utilities — one of the biggest shifts has been to increase automation in their technology strategy. Our industry has responded with a myriad of RPA-type solutions that aim to automate business processes through software and technology. RPA Tools are gaining greater intelligence through Hyperautomation, where RPA is further augmented with AI or machine learning. But very often just codifying and automating tasks carried out by people can deliver huge gains.

Our Work Management Platform — WorkEngine — provides RPA through a technology we have developed called Triggers. Uniquely, Triggers is integrated into the fabric of our platform and can be utilised at any time, allowing automation that is completely integrated into a customer’s working processes. The benefit of triggers is part of our Data Driven approach — helping to codify working knowledge, reduce risk, automate service delivery and allow teams to focus on high value actions and customer service instead of repetitive, mundane tasks.

Triggers utilises our WorkEngine Scripting technology, allowing highly bespoke functionality to be enacted in a consistent way across an entire business — across both back office and mobile based teams. Let’s take a look…

A Triggers Example

Let’s take a really simple example as to how Triggers work hand in hand with our Scripting tech. Let’s imagine you are a Windscreen Repair company and you’re completing an assessment for a customer that has non-standard requirements for replacement glass for their windscreen. Using WorkEngine’s Scripting technology, this logic can be encapsulated into a Script that operates on the platform that:

• Looks at the data captured by the engineer in the field
• Accesses the UK’s DVLA (Driver and Vehicle Licensing Agency) API to lookup the vehicle from its VRN to get the correct vehicle information
• Takes the DVLA Data and passes it to the national windscreen API to detect the product code for the type of glass
• Creates a new Order Task for a back-office team member to approve the order

This first part is easily taken care by creating a Trigger in WorkEngine that runs this Script any time a new “Assessment Job” is received by the platform. In WorkEngine it’s as simple as opening the Triggers section, and assigning this Script to the right action. We’ve just automated the process of looking up product information across two disparate APIs.

The back-office team member would automatically see the new Order Task in their queue of work and, once confirmed with the customer, could mark the Order as Approved. Do they have to manually contact their supplier to order the glass? Not with Triggers — it’s a simple task to create another Trigger that operates on Order Task ‘Approvals’ to go ahead and place the order with the supplier — perhaps by sending an email with the information required.

Triggers for IoT & Telematics

We’ve engineered Triggers to be a highly scalable technology that can deal with many thousands of incoming pieces of data every second. It’s not limited to changes that are made by humans — Triggers can perform actions based on data feeds from IoT and Telematics. Let’s imagine that you’re an FM Company and are recording sensor data from Building Management devices. These IoT Devices are streaming data into the WorkEngine platform. Every single data point can be interrogated by our Triggers technology to perform things like pattern matching, and run customer rules that can spot issues in equipment in the field — perhaps scheduling some pre-planned maintenance in a predictive way.

Triggers for Real-Time Analytics

True ‘Real-Time’ Analytics is becoming a standard requirement for many organisations. Generally speaking, with Field Service/Work Management solutions, businesses can go down one of two routes:

• Buy an off the shelf system, where the developer/supplier has pre-determined the metrics upon which you can report. They’ll have built some ETL Transformations/pipeline tech that takes your data and transforms it into something analytics friendly — like jobs completed per day, or hours worked per operative. How real-time it is depends on how quickly these processes operate — and if they haven’t got the metric you want it’s either a manual, offline operation for you to calculate, or a development request for the supplier
• Build something in house where you create your own Data warehouse, or connect it to your own Analytics tool to take transactional data, make some ETL transformations, setup a pipeline, schedule it to run every hour (surely 60 minutes is real-time enough?), test it with the business, optimise it out to try and run every 30 minutes because 60 minutes wasn’t actually frequent enough…you get the picture

One of the genius uses for Triggers is to build real-time analytics data. Triggers operate on data with a delay of milliseconds, and can generate analytics data that is instantly available for reporting and dashboards in WorkEngine’s Data Studio (or, indeed, in your analytics tool of choice).

How we architected Triggers

This is the bit for the geeks — how we actually architected Triggers. The diagram below gives a really high level overview of the architecture for how we deliver Triggers:

• Incoming data hits our API gateway. The API tracks changes to objects and pushes these changes as a Message (1A, 1B in example above) onto our at-scale Publish/Subscribe (Pub/Sub) infrastructure. Each object type in a customer’s system is an independent Topic in WorkEngine Pub/Sub, represented as a Queue
• At the point of ingestion into a topic, the change is replicated across multiple data centres, and is resilient to any one failure
• For each Trigger defined in WorkEngine, a subscription by our Triggers Services is maintained, with Pub/Sub pushing messages to the (replicated) Triggers Services.
• The Triggers Services is pushed a message, for each customer-defined Trigger
• Triggers manages our proprietary WorkEngine Scripting Runtime to execute the scripts required, which can be anything from interfacing with 3rd party APIs, updating analytics metrics, sending SMS messages and so on
• Once the script has completed, Triggers acknowledges the Message (ACK) back to Pub/Sub and the infrastructure marks the action as complete

Conclusion

Triggers is one of the key technologies interwoven throughout WorkEngine to provide our customers with an entirely integrated RPA, automation facility. Designed to help codify business rules, Triggers is able to perform actions based on any set of conditions a customer can think of to codify working knowledge, removing risk and automating service delivery.

‍

‍