Behind the scenes of the Waylay Digital Twin Salesforce Slack proof-of-concept

One thing that has become abundantly clear over the last months is that physical presence during office hours at the back office or at the customer site is no longer possible nor desired. Service organizations have to adapt to this new reality and there are plenty of software tools on the market that enables service professionals to work from anywhere. But are these tools efficient enough or do they lead to user frustration? Concretely, service professionals want to:

  • Configure or modify on the fly.
  • Access all the necessary data right there and now.
  • Leverage easy-to-use tools, no training required.
  • Update business rules frequently as regulations change, customer expectations change, product and service entitlements change
  • Collaborate in real-time with other team members.

Covid-19 has shown that working in field service is all about adapting to changing environments. The remote collaboration software tools alone are not enough to meet the above user requirements. They need to be equipped with intelligence that does the heavy lifting for you: enter Waylay Digital Twin for Salesforce Slack. 

It leverages the strengths of Salesforce Service Cloud, Salesforce Slack, Salesforce Flows, and the Waylay Digital Twin app.

Waylay Digital Twin Essentials

Waylay Digital Twin is a Salesforce ISV app that exposes IoT data and analytics within Salesforce. Combining IoT data with customer context drives a lot of business value. In the gamified demo described below, we will illustrate the power of Waylay Digital Twin to:

  • View real-time and historical sensor data
  • Provide proactive alerts, create cases & work orders, 
  • Integrate with Slack
  • Equip remote support with powerful diagnostic tools.

For more on these and other Waylay Digital Twin capabilities visit DigitalTwin

 

In order to show the strengths of our solution, we’ve built a little game around it. You are free to join our public Slack channel here and try it out yourself:

https://join.slack.com/t/waylaydigitaltwin/shared_invite/zt-vei0ipee-vcfGeI4epOS9cA8NleQMcA 

You can watch the video recording of the demo here: https://youtu.be/OmL9v4qEJso

The game goes like this: 

Your daughter has her heart set on seeing Princess Elsa at the Ice Palace but you have to get some work done today. As a service agent, you must ensure a clean playing environment. During your quest to Work from Anywhere, you might find that the Ice Palace Royal Robot Cleaners malfunction. You must solve this problem in time for your daughter’s visit with Princess Elsa. Your challenge will be to leverage the power of the Waylay Digital Twin and Salesforce to make your daughter’s dreams come true.

In short, there are two cleaning robots dispatched to clean the environment and the Waylay Digital Twin solution will help you to troubleshoot any issues that  occur.

Architecture and hardware

The robots that we used in our setup are toy robots equipped with sensors and actuators. We used the following hardware:

In order to simulate an overheating scenario, we put the LED board straight on the light sensor of the Electric Imp such that we see a sharp rise in light sensitivity when we turn on the LEDs.

In the Waylay Digital Twin App for Salesforce, you get full visibility into the real-time and historical robot sensor readings:

In the historical chart -which is a lightning web component- you can clearly distinguish a peak in the Light parameter values when we turned on the LEDs at the start of the game.

IoT monitoring and alerting

As a business user, we then created a proactive monitoring rule using the Waylay Digital Twin App that raises a Waylay Alarm in Salesforce when the Light parameter values are higher than a threshold of 60,000. The Waylay Engine subscribed to data from the IoT platform, evaluates it against our proactive monitoring rule and raises Waylay Alarm records in Salesforce.

We coupled this type of Waylay Alarm with a record-triggered Salesforce flow, that sends a block kit slack message down to our #dreamforce-demo channel.

We’re using text template variables with block kit code to construct the message and a custom Apex class to be able to send block kit messages down to a slack channel webhook URL.

The result is that we can send quite nice templated slack message alerts to the user, like this

You can also see various action buttons in the slack messages, e.g. Close Work Order, Launch Firmware update. 

To deal with such user interactivity, we have created our own Slack Bot: Waylay Digital Twin Slack bot. It was built using the bolt-js software framework. 

It also deals with the user slack commands (/help, /start and /end) and launches various Salesforce flows when the user clicks the buttons (e.g. close a work order). For interacting with the Salesforce back-end we used the jsforce software framework, concretely to launch Salesforce Flows.

 

In the above example, you can see another nice example of how our Slack bot integrates with the Waylay Digital Twin Diagnostic Test feature. A proactive alert message is posted on the Slack channel when we detect instability with the second cleaning robot. This alert is driven by another proactive conditional rule on the Waylay Engine. This time, however, we gamified the alert such that the user has to pick the right Waylay Diagnostic Test in order to find the problem with Robot B.

 

 

When the user selects one of the Waylay Diagnostic Tests, a standard Salesforce flow uses the Waylay Digital Twin SDK (Actions) to launch the selected test on the Waylay platform. These health check tests can be created by the business user in the same way as the proactive tests (see picture above). 

The difference is that the conditional diagnostic tests are executed once to evaluate the latest asset parameter values. They generate Waylay Diagnostic Test Result records in Salesforce and our Salesforce flow posts these results in the Slack channel. At the same time, the Salesforce flow creates both a new work order (to refill the oil) and a sales opportunity record because the customer might be interested in renewing his contract for an uninterrupted supply of the recommended oil brand.

 

As the demo progresses, we create and close work order and sales opportunity records in our Salesforce Organisation. You can view these on a public Salesforce Experience Cloud dashboard: https://waylayssportal-developer-edition.eu40.force.com/sfwaylaywfachallenge/s/ 

 

 

Another gem in this demo is the ability to remotely control the robot assets, for example ‘Launch Firmware Update’ button in the first screen above. These buttons launch Salesforce flows that trigger Waylay Digital Twin IoT device Apex Actions. They execute one-time device type specific action rules via the Waylay Engine. In this way, the standarized Apex Actions abstract the IoT platform-specific actions on the IoT devices. In this demo, we simulate the robot firmware update by controlling the LED lights of the robots.

 

Summarizing conclusions

You may think ‘wow this is a pretty complex demo to set up’, but it was created in about 2 weeks time. It was easy because:

  1. The Waylay Engine is very flexible in ingesting IoT data. No long set up times, no pre-provisioning necessary, etc
  2. Creating IoT pattern matching rules doesn’t require any development. You just create them using the no-code rule template creator of the Waylay Digital Twin App
  3. Salesforce flows are very easy to create and update using the flow builder. The recent Salesforce improvements on Flow Debugging are really useful.
  4. Creating and publishing a customer facing Experience Portal is literally 10 minutes work. Amazing.

 

Most of the time went into building the Slack Bot. I found that the default Slack Bot by Salesforce was too limited for our scenario. Also the standard Slack Post Message Apex Methods didn’t support block kit messages, just plain boring text. Instead, I decided to create my own Apex Class and Post Message invocable method, to be able to be able to post beautiful and emoji rich alerts to our slack channel from Salesforce Flow. I’m sure the Slack and Salesforce teams will improve on this in the future. 

 

The Slack developer documentation is a shining example of how developer documentation should be. Using bolt-js I quickly got a baseline bot going and from there on, we just incrementally added command and event logic.

 

Do you want to know more? Want to see the code? Contact us